dxdt.blog: занимательный интернет-журнал

В 2023 году я писал на dxdt.ru об одном из эффективных, для DNSSEC, способов динамического удостоверения факта отсутствия DNS-записи (или DNS-имени), который, в частности, применяют в Cloudflare. В конце 2025 года этот способ, с некоторыми добавлениями и обновлениями, получил спецификацию RFC 9824.

В частности, RFC 9824 вводит “мнимую” DNS-запись NXNAME (TYPE128) – это запись-сигнал об отсутствии в DNS-зоне запрошенного имени. Причина для введения такого сигнала в том, что упомянутый способ в принципе не позволяет отвечать со штатным для DNS статусом NXDOMAIN. Почему? Потому что весь смысл состоит в “подделывании” состава ответа, но, так сказать, с благими целями: при получении запроса о несуществующем имени, авторитативный сервер отвечает так, как если бы для этого имени нет DNS-записей в зоне: ANSWER: 0 и флаг NOERROR. В терминах DNS такой ответ называется NODATA – то есть, это корректный DNS-ответ без статуса ошибки, но пустой – не содержащий никаких ответных, – в блоке ANSWER, грубо говоря, – записей (естественно, это не означает, что DNS-ответ в целом не содержит записей: пуст только блок ANSWER, но записи в ответе есть, это дополнительные, “авторитативные” записи – SOA, NSEC и т.д.).

Однако, логически, NODATA – это не NXDOMAIN. Статус NXDOMAIN специально предназначен для указания на отсутствие самого имени. Действительно, если нет имени, то для него не может быть и никаких DNS-записей. Понятно, что и NODATA укладывается в схему, но с той лишь точностью, что NODATA – это отсутствие записи конкретного типа, пусть для несуществующего имени и нельзя разместить никакую запись, никакого типа. То есть, NXDOMAIN – мощнее, поскольку указывает на отстутствие самого имени. (Это всё может показаться сложным. Если так, то это не кажется: DNS вообще весьма и весьма непростая система. Зато, заметьте, что здесь очередной раз обыгрываются различные трактовки понятия “пустое множество”.)

Для того, чтобы в новой схеме отличить ситуацию, когда действительно нет записей, от ситуации, когда нет имени, как раз и служит новая запись-сигнал NXNAME. Авторитативный сервер указывает NXNAME в составе полей NSEC-записи, если нет DNS-имени. NSEC – это запись, обозначающая “границу” зоны (в данном случае – фиктивную границу), NSEC нужна для того, чтобы было что подписывать, так как нельзя подписывать пустое значение. Технически, подписать-то можно, но такую подпись легко скопировать и применять к отсутствию любых записей в DNSSEC, то есть в безопасной DNS-зоне: это как раз пример того, что все пустые множества одинаковые, а окрашивать можно только пустые коробки, вот как в случае с NXNAME/NODATA и NXDOMAIN.

Здесь играет роль ещё одна нетривиальная особенность DNS, которую мало кто понимает. А именно: в DNS распространены ситуации, когда возникают заведомо пустые, но поименованные, фрагменты имени. Предположим, что есть имя a.b.c.example.com, для которого указана A-запись. Это имя находится в зоне example.com, но A-запись указана только для a.b.c. Как трактовать имя b.c.example.com (без a.)? Оно, вроде как, есть, потому что в DNS полное имя строится в форме иерархии лейблов, разделяемых точками. Но, не менее “вроде как”, этого имени и “нет”, потому что для него в принципе не указаны никакие записи: из “полных” имён тут будет только example.com и a.b.c.example.com. Для корректной обработки такого случая, в схеме, где NXDOMAIN-ответ невозможен, нужен сигнал, позволяющий отличить несуществование имени от несуществования записи для этого имени. Это и есть NXNAME.

Конечно, занимательно. Но, другое дело, что, с одной стороны, новый подход позволяет быстро, в онлайн-режиме генерировать подписанные DNS-ответы, удостоверяющие отсутствие запрошенной записи или отсутствие имени. С другой стороны, логика DNS очередной раз усложняется, а клиент, резолвер – должен подерживать обработку NXNAME, иначе для него разные пустые коробки склеиваются в одну (отсутствие записи склеивается с отсутствием имени).

На Hackaday – попытка построить радар с ФАР (AERIS-10) на базе открытой архитектуры и из доступных комплектующих. Сантиметровый диапазон: частота 10.5GHz. Низкоуровневую “радарную” работу реализуют на FPGA и готовых формирователях луча, общее управление – на микроконтроллерах STM32. Предусмотрено механическое сканирование по азимуту и привязка к GPS-координатам.

Надпись под картинкой X-76 SPRINT на сайте DARPA: “Artist’s concept for the SPRINT X-76, a proof-of-concept technology demonstrator that aims to demonstrate technologies and concepts needed for runway-independent, high-speed flight”. Вчитайтесь в повторы слов: концепция (concept) концепции о технологическом демонстраторе, нацеленном на демонстрацию технологий и концепций… и так далее. Видимо, чтобы слов хватило на нужную длину строки. Как говорится, ИИ-LLM, несомненно, идёт на смену копирайтерам, в том числе, и силами самих копирайтеров.

(Речь в пресс-релизе о некоторой “концепции о концепции” некоторого реактивного конвертоплана с “гибридными” движителями: такой продвинутый вариант V-22 Osprey, как бы из компьютерной игры, только ещё сложнее, потому что не только поворачиваются мотогондолы и меняется конфигурация крыла, но ещё и лопасти складываются в полёте. С крейсерской скоростью в 400 узлов и не требует оборудованной полосы для разбега. Впечатляет. Если верить картинкам, конечно. Всё с планами на 2028 год и далее. То есть, пока что ничего интересного, но выглядит так, как если бы без LLM не обошлось.)

Ещё в копилку реального использования LLM, но, в данном случае, “картиночных”.

Это ChatGPT современной версии (которая доступна через веб-интерфейс на бесплатном аккаунте, видимо, какая-то 5.x). Попробовал старинный запрос – нарисовать настенные часы. Но в этот раз – с 11-часовым циферблатом (такие картинки полезны, когда нужно объяснить арифметику остатков, например, сравнивая составное 12 и простое 11). Пишем достаточно подробный, на мой взгляд, промпт на русском (специально):

“Нарисуй настенные часы с 11-часовым циферблатом, которые показывают без двадцати десять”.

Казалось бы, прошло уже несколько лет “улучшений” и хайп только набирает обороты, но, к сожалению, результат, как обычно, не слишком-то полезный – см. ниже.

(Здесь двенадцать часовых отметок, но две обозначены символом “11”, да и стрелки показывают не 9:40.)

Типовая спутниковая навигационная система (GNSS, типовой пример – GPS) работает в модели, когда приёмник “смотрит” на спутники, а спутники – приёмник не видят: спутники лишь излучают сигнал с метками. Приёмник, на основании полученных данных о местоположении спутников, определяет собственное положение в пространстве (относительно спутниковой системы координат, естественно).

Такой подход выглядит пассивным, в том смысле, что приёмник только принимает сигнал, но никак не участвует в формировании навигационного поля: не передаёт запросов, не отвечает подтверждениями. То есть, в теории, если считать, что GPS-приёмник полностью пассивный (это не всегда так с приёмниками радиосигналов), то схема получается достаточно скрытной: собственные координаты поступают, но не уходят – нельзя узнать положение приёмника (через навигационную систему). Но координаты нужно вычислять, и делать это нужно относительно того, как “видны” спутники с точки зрения приёмника (его антенны/антенн, если говорить совсем строго). Это сопряжено с проблемами спуфинга и помехопостановки: приёмник может принимать дефектный/поддельный сигнал, не принимать ничего вовсе, кроме помех, а сама внешняя система – не знает про такую ситуацию конкретного приёмника, поэтому никак не может содействовать в улучшении его сигнального положения (например, в сетях мобильной связи с условным обозначением 5G, это не так – зная положение приёмника и его “электромагнитную ситуацию”, можно резервировать лучи для этого прёмника).

Вообще, вспоминая сети подвижной радиосвязи, можно представить источник навигационной информации уровня GNSS, работающий по схеме, обратной к только что описанной, но при этом всё равно “пассивной” для потребителя – “только на приём”. Местоположение потребителя геолокации определяет сеть, а потом передаёт этому потребителю его координаты, как они видны с точки зрения сети, в готовом виде. Вот только местоположение потребителя определяется не по исходящему от него специальному радиосигналу, а по сопутствующим признакам: визуально, по возмущениям вокруг, по помехам, источником которых является этот потребитель, ещё как-то.

Например, представьте, что у нас есть много космических спутников на низкой орбите и некоторый летательный аппарат в атмосфере, который нуждается в коррекции своих коордиант. Часть спутников видит этот аппарат, потому что, предположим, спутники как раз предназначены для наблюдения за такими летательными аппаратами и оснащены ИК-сенсорами, телескопами и радарами. Теперь эти спутники вычисляют географические координаты той точки, где видят аппарат, и передают их в сторону аппарата, например, по радио (но тут возможны и варианты – см. ниже). Естественно, это просто вариант давно и широко известной коррекции “по месту”, которая выполняется специальным наблюдателем. Только тут всё автоматическое и работает на базе сети спутников.

Что поменялось? Исходная система-источник геопривязки осталась спутниковой (это важно – спутники могут покрывать сигналом всю территорию Земли), аппарат остался с приёмником, но теперь приёмник получает сразу координаты, их не нужно вычислять, и это координаты с точки зрения внешней навигационной системы. Этой внешней системе гораздо сложнее поставить помеху с земли, а тем более, “подспуфить” сигнал. Но, как и в исходном варианте, можно задавить помехой нисходящий канал на стороне приёмника – последний не сможет принимать координаты, поступающие из внешней системы. Другое дело, что для передачи координат достаточно канала с малой пропускной способностью, и не требуется целая схема кодов для передачи “таймингов” с наносекундной точностью.

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

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

Кстати, что касается URL (URI), как носителя “секрета”, установленного в составе адреса документа или параметров URL: ещё в 2015 году, десять лет назад, “Яндекс.Браузер” собирал URL, которые посещает пользователь, и отправлял их поисковому роботу “Яндекса”, чтобы тот индексировал контент для всех пользователей поисковой системы (этот подход сильно напоминает теперешнее “обучение ИИ”, кстати). Так что, полагаясь на “секретность” URL (что само по себе очень плохо), браузеры-то как-то неправильно вычёркивать из перечня каналов утечки. Браузер исполняет веб-интерфейс, а не пользователь “на бумажке”, так что URL могут уходить куда угодно именно потому, что это URL.

Заметьте, что URL – это не авторизационный куки-файл, который браузеру тоже известен, но который передаётся в составе заголовков HTTP-запроса, поэтому чётко отделяется в любом браузере от URL, и браузер, всё же, этот файл будет пытаться отправлять только тем узлам, которым он прямо предназначен (на сей счёт есть очень много спецификаций и требований, а про URL – подобных требований нет).

Известная шутка гласит, что категорий людей – 10: одни уже знают двоичную систему счисления, а другие – ещё нет. Занятно, что 10₂ обозначает простое число – два. Это большая редкость в системах счисления, которые рутинно используются в ИТ. Понятно, что ни в восьмеричной, ни в десятичной, ни в шестнадцатеричной, 10 (как запись) не может обозначать простое число (как и всякая запись, заканчивающаяся на 0). А в двоичной – пожалуйста.

Естественно, это возможно только потому, что основание двоичной системы – простое число два. Если взять любое другое простое основание, то 10 тоже будет простым, потому что это и есть запись основания: три – по основанию 3, пять – по основанию 5, семь – 7, и так далее. Но наиболее привычны, кроме десятичной (десятеричной), это двоичная, восьмеричная и шестнадцатеричная.

Возьмём запись 11. В двоичной – это простое число три (11₂ = 2 + 1 = 3). В восьмеричной – девять, составное, но квадрат простого: 3^2. Та же запись 11 означает одиннадцать в десятичной, простое. Шестнадцатеричное 11 – это семнадцать, тоже простое.

Использование в этом ряду двоичной системы ограничивает доступный набор цифр: только 0 и 1. Но можно взять, например, 101 – трёхзначное:
это пять в двоичной (простое);
шестьдесят пять – в восьмеричной, составное: пять на тринадцать;
сто один – в десятичной, простое;
двести пятьдесят семь – в шестнадцатеричной, простое.

Обратите внимание, что запись чисел словами – это инвариантная, относительно системы счисления, запись.

111₂ = семь (простое);
111₈ = семьдесят пять (составное);
111₁₀ = сто одиннадцать (простое);
111₁₆ = двести семьдесят три (составное: 3*7*D).

Не забывая о том, что все простые числа, кроме числа два и числа три, имеют вид 6*n +/- 1, на трёх цифрах можно и остановиться. Тем более, что шестеричная система счисления не является распространённой.

В продолжение записки о том, что появится новый тип УЦ (Удостоверяющих Центров) для выпуска TLS-сертификатов, базирующихся на хеш-деревьях (деревьях Меркла). Речь в этой заметке не про технические детали (про них, возможно, будет отдельно в другой заметке), а про изменение технологических и административных процессов в работе УЦ, которые с новым подходом связаны. Сейчас пока что всё существует в виде тестов и черновиков RFC, но можно ожидать быстрого перехода УЦ на описанную схему. Примерно так же, как было с внедрением обязательных SCT-меток (от логов Cetrificate Transparency) в сертификаты: браузеры начинают верить только в сертификаты с правильными SCT-метками – УЦ для веба вынуждены подстроиться.

Новая схема работы радикально переиначивает логику деятельности УЦ. Дело в том, что полностью меняется фундаментальный процесс: УЦ должны вести собственный лог выпуска сертификатов, который лог становится необходимым источником сертификатов. Да, именно так. Потому что сертификаты, в новой схеме, образуются в результате корректного ведения лога. Это весьма существенное изменение: фактически, то, что сейчас реализуется Certificate Transparency, заносится внутрь УЦ и становится строго первичным, фундаментальным процессом.

Сейчас набор технологий и сервисов, который называется Certificate Transparency, реализуется внешним, относительно деятельности УЦ по выпуску сертификатов, образом. В новом варианте, при штатной работе, УЦ не сможет выпустить сертификат, не внеся прежде соответствующие записи в свой лог сертификатов и не получив на этих изменениях подписей от третьих сторон – эти третьи стороны выступают гарантами всего процесса, их подписи – необходимы для валидации сертификата.

Собственный лог УЦ как раз и ведётся в форме хеш-дерева. В сертификат нового типа обязательно должны быть добавлены артефакты из лога (доказательство включения в дерево), что и ставит внесение записей в лог выше процесса выпуска сертификата.

Да, сейчас УЦ должны получать SCT-метки с подписями логов Certificate Transparency (CT), чтобы внести эти метки в сертификат. То есть, процесс выпуска сертификата уже завязан на те или иные CT-логи, что, конечно, делает его похожим на предлагаемый новый вариант. Однако в новом варианте есть целых три существенных отличия:
1) УЦ обязательно ведёт свой лог, который необходим для формирования сертификатов (но это не отменяет других логов);
2) вводится два типа сертификатов, и даже в “полный” сертификат включаются сведения из лога, с подписями нескольких строн, а не просто подпись УЦ на конкретных данных (как сейчас);
3) основной метод оптимизации – сертификаты без подписи, которые содержат только доказательства включения в лог.

И вот главное из этих трёх нововведений – это сертификаты без подписи (“бесподписные”).

Почему весь смысл в сертификатах без подписи? Потому что только такие сертификаты позволяют отказаться от больших подписей криптосистем с постквантовой стойкостью. В этом смысл оптимизации. Да, тут нетрудно заметить ещё один занятный момент: речь про ML-DSA, а там, действительно, подпись занимает несколько килобайтов; казалось бы, и квантовые компьютеры выглядят теоретическим построением, и никто не доказал, что большой размер подписи является необходимым условием постквантовой стойкости – тем не менее, именно многокилобайтные подписи оказываются существенным фактором внедрения сертификатов без подписи и новой схемы работы УЦ. Впрочем, необходимо отметить и то, что схема с хеш-деревьями позволяет существенно экономить трафик уже и для RSA-подписей (с разрядностью 4096 бит и больше).

Чтобы работать с сертификатами без подписи, чтобы валидировать их, нужны свежие копии узлов доверенных деревьев (поддеревьев, если точнее), которые покрывают эти сертификаты. То есть, получается, что валидирующая сторона (браузер, предположим) будет достаточно часто скачивать обновления деревьев для валидации сертификатов. И если обновление получить не удалось, то сертификат без подписи будет считаться невалидным. Но, естественно, можно использовать “полный сертификат”. (Тут ещё есть отдельная история про то, как с новой схемой соотносится отзыв сертификатов, но её оставим для другой записки.)

Узел, запрашивающий выпуск нового сертификата у УЦ, может получить практически сразу же “полный сертификат” и, с некоторой задержкой, оптимизированный сертификат без подписей. Соответственно, TLS-сервер, при установлении TLS-соединения, мог бы выбирать, какой сертификат отправить клиенту, в зависимости от сигналов в начальном сообщении клиента. В TLS планируется добавить расширения, которые позволят информировать сервер о списке доверенных состояний деревьев (логов), которые известны клиенту. Так что, если сервер видит, что клиент не сможет валидировать оптимизированный сертификат (без подписей), то сервер присылает полный сертификат.

Понятно, что если сертификат полный, то нет ни экономии трафика, ни экономии вычислительных затрат на проверку подписей – то есть, довольно сомнительная затея: поэтому, конечно, основной расчёт на то, что большинство клиентов (веб-браузеры) будут оперативно обновлять списки доверия, скачивая их из каких-то точек раздачи, и принимать “бесподписные” сертификаты при соединении с веб-узлами. Получаем привязку к новой технологии и её провайдерам, в форме токенов доступа: если ваш клиент вдруг отстал от обновления дереьвев, то, как минимум, приходят “медленные” большие сертификаты, а как максимум – невозможно штатно заходить на веб-сайты и подключаться к TLS-узлам, потому что они все перешли исключительно на “бесподписные” сертификаты, в целях оптимизации. Если сейчас нужная для валидации информация, кроме статуса отзыва, есть в самом сертификате, то с “бесподписными” сертификатами – это окажется совсем не так.

То есть, в схеме с хеш-деревом и “бесподписными” сертификатами нужно регулярно скачивать обновления хеш-дерева. Заметьте, кстати, что TLS-расширение с поддерживаемым списком – может использоваться для профилирования и распознавания клиентского ПО по составу трафика. Хуже того, если забанят доступ к точкам раздачи обновлений хеш-деревьев, то перестанут работать веб-сайты с “бесподписными” сертификатами, и обойтись отключением “онлайн-проверки” статуса, как в случае с OCSP, уже не выйдет.

Отмечу отдельно некоторые записки, вышедшие в феврале 2026 года:

• Обобщения и квантовая криптография
• Выбор параметров криптосистем и NUMS
• Комплексные числа, отношение порядка и квадратные корни
• Пустое: множество и коробка
• TLS-сертификаты и проверка “по IP-адресу”

В Google планируют уже в следующем году начать строить в браузере новую инфраструктуру УЦ для TLS, используя схему с доказательствами на деревьях Меркла (хеш-деревьях) в оконечных сертификатах.

Это, технически, совсем другая история, по сравнению с действующими сейчас способами выпуска и публикации TLS-сертификатов. Доказательства принадлежности к дереву используются вместо подписи в сертификате. Это, фактически, перенос технических идей Certificate Transparency внутрь самих сертификатов. Я писал об этом новом подходе не так давно. С одной стороны – довольно интересная, изящная технология. С другой стороны – тут просматривается ещё большая технологическая привязка к тому же Google (потому что нужен будет совместимый TLS-стек в браузере, а реализовать такие технологии независимо – мало кому сейчас по силам; посмотрите хоть бы на внедрение ACME: там практически везде “готовые библиотеки/скрипты”, на обоих концах, что называется – мало кто понимает, как работает, но все используют и встраивают в свои системы на правах “чёрного ящика”). Но интересно, факт.

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

В сообщении Google (по ссылке выше) есть ещё интересный момент: там пишут, что к концу этого года ожидают (возможно, в Chrome/Chromium) поддержку X.509-сертификатов с “обычными” “постквантовыми подписями” для непубличных PKI (для УЦ, которые не входят в “коробочный” список доверия браузера). То есть, в браузере может появиться поддержка криптосистем подписи с постквантовой стойкостью в сертификатах. Это довольно занятно, так как позволит использовать такие сертификаты хоть в каких-то браузерах. (Но это ещё нужно посмотреть, что там реально будет.)

Сейчас практически постоянно пишут и говорят про “ИИ в математике”. Типа, какие “достижения”. Понятно, что инструмент перебора – может доставать какие-то доказательства кусками из ранее опубликованных работ, “синонимизировать” их, собирать из них другие доказательства и прикреплять к “нерешённым задачам”, например, из списков Эрдёша (где относительно много довольно простых, для специалиста, задач). Такой поиск перебором даже может быть полезен (но по модулю избыточных ресурсов, конечно).

Перебор – перебором, но LLM-перебор – это совсем не тот перебор, который вполне себе является методом математического доказательства. Например, как метод доказательства, перебор позволяет быстро находить контрпримеры к каким-то утверждениям. Элементарная иллюстрация: допустим, кто-то говорит, что нельзя “квадрат разложить на два квадрата”; это легко опровергнуть, просто “подобрав” самую известную пифагорову тройку: 3^2 + 4^2 = 5^2. Естественно, компьютеры существенно улучшили возможности по перебору: несравнимы возможности современного ПК и даже таких признанных вычислителей, каким был Эйлер. Однако всё это без учёта новомодных LLM, в которых, похоже, вычислительный ресурс в основном расходуется впустую.

А вот насколько точны результаты компьютерной обработки, применительно к теоретической математике, и как их интерпретировать – вопрос довольно сложный, скорее философский. По крайней мере, проблемы возникают с действительными числами, которые для компьютеров недоступны в принципе. Хуже того, несмотря на большую мощность, компьютер в принципе не может заглянуть даже в область действительно больших натуральных чисел. Но это всё сложные моменты, которые ничуть не отменяют того факта, что компьютеры давно влияют на теоретическую математику. И дело тут ни разу не в модных LLM.

Вообще, интересующимся темой, я бы порекомендовал серию прекрасных статей Н. А. Вавилова, которая начала выходить ещё в 2020 году, до всего этого “хайпа” с LLM “в математике”, и к LLM никакого отношения не имеет: “Компьютер как новая реальность математики” – вот где действительно есть тематическое содержание.