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

В декабре 2024 года я писал на dxdt, что эффективным направлением применения ИИ-LLM к математическим задачам был бы поиск контрпримеров к более или менее известным утверждениям, в формате компьютерного доказательства. В качестве примера сборников подходящих задач я приводил “Коуровскую тетрадь” (это широко известный в узких кругах канонический список задач теории групп). Цитата из той записки:

Для заметной части из этих проблем и связанных задач можно было бы отыскать контрпримеры (и даже просто – примеры), используя современные возможности по оптимизированному перебору текстов компьютерных доказательств.
[…]
То есть, это самое реальное применение для знаменитых “LLM с нейросетками” на ближайшее время, при котором они могли бы оказаться очень эффективными для математических исследований.

Ну, идея довольно очевидная, поэтому, кто бы сомневался, что именно так и вышло: на днях OpenAI опубликовали список из десяти достаточно известных математических проблем, к которым предложены решения или контрпримеры, найденные “методами ИИ”, с использованием Lean.

Интересно, что одна из решённых в OpenAI задач – прямо указана и в “Коуровской тетради”, но лишь в самой свежей, 21-й редакции (я проверил только для англоязычной версии, понятно). В публикации OpenAI – это третья глава с утверждением non-sofic groups exist и контрпримером – с построением такой группы. В англоязычной “Коуровской тетради” это задача 21.86. Да, там обратная формулировка: “всякая ли группа является софической (sofic)?”. Но это как раз то, что нужно для поиска контрпримера: покажите одну группу, которая non-sofic, и это даст ответ – нет, не всякая. (“Софической”, конечно, не лучший перевод – должно быть “терминальной” или “терминируемой”, но данный вариант уже занят.)

Но что особенно занятно, так это то, что решённая ИИ OpenAI задача 21.86 в тетрадь добавлена в этом же, 2026 году! Удивительное совпадение. Например, препринт на Arxiv с 21-м изданием, в котором появляется данная задача, датирован январём 2026 года (версия 39, кому интересно). Естественно, сама исходная гипотеза про “софичность” всех групп – сильно старше, она, примерно, 2000 года. Однако в более старых версиях “Коуровской тетради” она не указана, а, похоже, появляется только в 2026 году.

Иногда приходится слышать, что, мол, не нужно на уровне гипервизора применять различные фильтры и ограничения для сетевого трафика виртуальных машин, исполняемых под управлением этого гипервизора и, соответственно, гостевых операционных систем (ОС). Дескать, трафик всё равно фильтруется на стороне гостевых ОС, мы там настраиваем правила в Netfilter. А если сломали “гостей”, значит – уже и так сломали. Это, конечно, неверный подход.

Фильтрация, как мера обеспечения информационной безопасности, необходима и на стороне гипервизора. Речь здесь не столько про “вредоносный трафик”, – что бы это ни значило, – а про алгоритмы различных практических атак, направленных на получение управления и виртуальной машиной (VM), и, следом, самим гипервизором (такое возможно, не сомневайтесь). И, конечно, тот факт, что используются “виртуальные интерфейсы”, поэтому те же сетевые пакеты, которые попадут в ядро гостевой ОС, проходят и через ядро ОС гипервизора, вовсе не отменяет необходимости фильтрации гипервизором. Вот вам несколько поводов для внедрения фильтров и контроля сетевого доступа на уровне гипервизора.

1. В ОС на гипервизоре не оказалось нужной уязвимости, для эксплуатирования которой требуется отправка сетевых пакетов. Ну, то есть, не за что зацепиться. А вот в ОС, исполняемой в виртуальной машине, уязвимость есть. Если пакет не добрался до виртуальной машины, то пакет не повредил ни машине, ни гипервизору. Это, пожалуй, самая простая, банальная причина применять фильтры на уровень выше, чем находятся внутренние интерфейсы VM.

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

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

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

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

В Anthropic пишут, что в августе начнут (или уже начали) добавлять специальные “метки происхождения” в тексты и другие материалы, которые генерирует ИИ-LLM Claude. Метки должны обозначить то, что текст сгенерирован данной LLM (ну или сгенерирована картинка, или ещё что-то).

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

Вообще, с подобными, – но невидимыми, – метками интересен совсем другой аспект: грамотно сконструированные метки позволят определять не просто LLM-источник, но конкретное происхождение текста (не только текста, понятно: то же применимо и к картинкам, и к видеофайлам). Это даёт мощный механизм влияния. Я писал об этом в 2024 году:

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

Несколько месяцев назад, в конце марта 2026 года, я публиковал на dxdt.blog ссылку на занятную языковую задачку из газеты The Guardian. В задаче нужно было сопоставить последовательности разноцветных прямоугольников фразам на английском языке. Цитата:

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

Тогда я попробовал эту задачу задать ChatGPT (естественно, после того, как решил все фразы сам, чтобы было с чем сравнивать), но LLM не смогла угадать ни одной фразы.

Решил вот на днях повторно эту же задачу проверить. Что ж, то ли потому, что развитие LLM идёт очень быстро, то ли потому, что к исходной задаче опубликовали ответы и эти ответы стали доступны для включения в базу LLM, но теперь задачу отлично и без ошибок решили и ChatGPT (уже GPT-5.6 Pro), и Claude (уже Opus 5 Max).

Если верить “техническому описанию”, которое сейчас показывают обе системы, то ChatGPT использовало разбиение картинки на блоки для того, чтобы сравнивать размеры блоков с глифами по шрифтам, перебирая записи подходящих фраз (ну, то есть, это мог быть как грубый перебор, так и более ловкий подбор по базе текстовых связей LLM), а Claude использовало скрипты на Python, чтобы разобрать исходное изображение на блоки и посторить для них статистику (по высоте, цвету и пр.), под которую потом тоже подобрало текстовую запись фраз по шрифтам (опять же, интерепретировать это точно – невозможно: нет подробных данных). Обе LLM написали, что учитывали структуру последовательностей гласная/согласная.

Естественно, обе ИИ/LLM-системы верно отметили цитаты из Шекспира (Claude с гиперссылками на исходные тексты даже, но это, скорее всего, связано с настройками конкретного аккаунта), и указали на использованную оригинальную запись: glisters в “All that glisters is not gold” (сейчас, скорее всего, написали бы glitters, но это неверно).

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

Появилась новая публикация (Daniel R. Simon), предлагающая квантовый алгоритм, взламывающий – теоретически! – криптосистемы типа ML-KEM/ML-DSA за полиномиальное время (то есть, атака предложена на задачу, лежащую в основе предположения о стойкости, в том числе, ML-KEM/ML-DSA, но подходит не только для них). Для работы алгоритма потребуется подходящий квантовый компьютер – уже этим многое сказано. Однако пока что и сама работа опубликована в статусе черновика, о чём там прямо сказано. То есть, скорее всего, – найдутся ошибки.

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

Если же ошибки в упомянутой выше работе не найдутся быстро, то это будет означать, что для атак на постквантовые алгоритмы предложен квантовый алгоритм. Это занятно. Но в этом нет никаких противоречий: почти вся практическая современная постквантовая криптография строится из предположения стойкости к алгоритму Шора, а вовсе не к мифическому “перебору на квантовом компьютере”, который придумали в газетах и о котором едва ли не повсеместно в тех же газетах сейчас пишут. Это всё, без всяких оговорок, прямо применимо к ML-KEM/ML-DSA: никто не доказал, что нельзя разработать квантовый алгоритм для эффективного взлома этих криптосистем – есть только рассужения о том, что алгоритм Шора к ним не подходит (если вдруг вы хотите в нескольких словах узнать почему не подходит, то вот: потому что там, в атаке на ML-KEM/ML-DSA, нельзя прямо применить алгоритм нахождения периода некоторой функции). Но специальный квантовый алгоритм, отличный от алгоритма Шора, вполне может существовать. Даже так – скорее всего, такой эффективный алгоритм есть, его только нужно найти и описать, а это очень сложно.

Что будет означать появление описания квантового алгоритма, эффективно взламывающего ML-KEM/ML-DSA и другие криптосистемы под собирательным обозначением “на решётках”? Это точно не приблизит к реальности сами универсальные квантовые компьютеры, но зато создаст вполне себе хорошее обоснование для того, чтобы либо улучшать стойкость ML-KEM/ML-DSA и прочих “решёточных” криптосистем, либо переходить на другие криптосистемы. И это будет весьма забавно: для атаки на постквантовые криптосистемы предложены новые теоретические квантовые алгоритмы, поэтому нужны суперпостквантовые криптосистемы, устойчивые и к алгоритму Шора, и к новому алгоритму “Имярек”.

Посмотрим, в общем, что там предложат. Так или иначе, но считать ML-KEM/ML-DSA неприступными – точно ещё рано.

Тем временем, для игры Quake продолжают выходить дополнения и новые уровни, в том числе, вполне официальные (ну, с учётом административных пертурбаций, приключившихся за тридцать прошедших лет): юбилейное дополнение называется Dawn of the Machine. За Quake, конечно, необходмо записать заметное историческое влияние на мир компьютерных игр, но, всё же, по данному показателю – это далеко не Doom.

Для некоторых доменов в .ru, которые ранее я зарегистрировал, регистрация закончилась. Соответственно, они переделегируются на специальные NS регистраторов. Продлевать регистрацию я не планирую – не вижу смысла: ЕСИА, да ещё и цены стали совсем немалые. Сегодня вот пришлось заниматься экстренным удалением одного из технических имён .ru, которое я не успел раньше вычеркнуть из DNS-зон, а оно, оказывается, уже закончилось. Вроде, тоже поправил. На dxdt.blog это не должно было повлиять, но всё же.

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

Удивительное всё же дело. Но, надеюсь, что хотя бы управление другими доменами, которые не в .ru, .su, .рф, пока останется. Посмотрим.

Обновил на основном сервере dxdt.blog операционную систему до Debian 12. Обновление, понятно, принесло с собой некоторые минимальные несовместимости (например, в какой-то момент отломился PHP – надеюсь, никто не заметил), но, вроде, сейчас всё работает нормально. Если нет – пишите почтой.

Вчера сайт был несколько часов недоступен, но по другой причине, которая напрямую не связана с обновлением ОС. Вчера проблема возникла с созданием “снапшота” виртуальной машины.

Вообще, я не сторонник “снапшотов”. Я всегда говорю, что “снапшот” – это последнее, на что можно рассчитывать при каких-то сложных работах (восстановление должно происходить не “откатом”, а “перекатом”, говорю я, – но это тема для другой записки; тем более, что я же, – иногда, – шучу в адрес специалистов DevOps, что, мол, “бэкапы – это для трусов”).

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

Наткнулся тут случайно на занятное решение в области внутреннего устройства LLM-системы Claude от Anthropic.

Я на днях попросил эту систему извлечь актуальный TLS-сертификат с некоторого веб-сервера (HTTPS, то есть). В ответ пришло подробнейшее объяснение того, что “песочница” на стороне Anthropic, которую данная система использует внутри, чтобы выполнять команды, перехватывает TLS, подставляя сертификат, сгенерированный TLS-прокси. “Песочница” тут – это контейнер или виртуальная машина, где исполняется системная среда, доступная “бэкенду” LLM. Сейчас все современные мощные системы этого типа максимально используют привычные программные среды и утилиты (Python, Bash, curl, OpenSSL и пр.), выдача утилит “подмешивается” в процесс подготовки ответа, и это даёт несравнимо лучший результат, чем простое “поточное генерирование” (банальный пример – арифметика: так как “привычный подход” приводит к смешным ошибкам, продвинутые системы ИИ-LLM уже давно считают числа при помощи скрипта на Python).

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

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

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

Зачем такой перехват может быть сделан? Чтобы отслеживать трафик внутренних систем, управляемых LLM – в трафике может быть что-то подозрительное. Можно было бы делать более тонкий перехват, но это очень сложно, а примитивный “тотальный MITM” – работает подобно молотку: не избирательно, зато просто и предсказуемо.

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

Схема, применяемая на бэкенде Anthropic, – согласно описанию, данному Claude, – несколько другая, но очень похожа: TLS-прокси подменяет всё подряд, и выдаёт сертификаты даже для заведомо несуществующих DNS-имён, под которыми нет никаких веб-узлов (имеется в виду имя в поле SNI). Насколько это оправданно? Опять же, сложно сказать. Зависит от целей. С одной стороны, это полностью искажает сетевую реальность и сводит к нулю ценность такой среды, в которой, тем не менее, LLM-система что-то запускает и пытается использовать результат, растрачивая немалые вычислительные ресурсы. С другой стороны, система вынуждена “искать обходные пути”, и успешно находит их, – это потом можно представить в газетах как “взлом”, обход “ограничений безопасности” и “выход из песочницы”.

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

Воскресное чтение манускриптов. Продолжение разбора задач из “Арифметики” Диофанта в версии манускрипта Vat.gr.191 (13 век, Ватиканская Апостольская библиотека).

Часть вторая. Первая часть заканчивается разбором формулировки первой задачи в конкретных числах: 100 == X + (X + 40). Если не читали первую часть, то имеет смысл прочитать, ну, перед тем, как приступать ко второй.

Вообще, первая и вторая части тут относятся к одной записке, из которой я решил сделать две, так как рубрика что-то очень редкая. При этом, данный манускрипт с “Арифметикой” (а там не только “Арифметика”, которая начинается с листа 360r) встречался на страницах dxdt уже несколько раз. И, возможно, ещё встретится (если доступы к онлайн-архиву останутся). Так что эта “вторая часть” – это локальная вторая часть, и она посвящена дальнейшему разбору записи первой задачи.

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

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

Анахронизмы – анахронизмами, конечно, но ведь даже доступные манускрипты – это далеко не исходные публикации, а переписанные спустя несколько веков ныне утраченные “исходники” (в кавычках – потому что непонятно, что за материалы использовались на самом деле). Так, рассматриваемый здесь манускрипт Vat.gr.191, согласно его датировке, почти на тысячу лет моложе, чем период, когда действовал сам Диофант. Но тут уж ничего не поделать.

Вернёмся, впрочем, к самой формулировке первой задачи. Ещё раз общий вид фрагмента с задачей со скриншота манускрипта.

В прошлый раз остановились в самом начале третьей строки и разобрали большую редакторскую правку, которая записана слева.

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

Здесь (в современной типографике) написано: συναμφότεροι ἄρα γίνονται ἀριθμοὶ δύο μοναδες μ̅· δέδονται δὲ μονάδες ρ̅. Максимально близкий перевод: “Вместе, таким образом, выражают неизвестную дважды, единиц 40: даёт же [всего] единиц 100”. Здесь μ̅ и ρ̅ это числа 40 и 100, соответственно, но обозначены эти числа буквами (с чертой, overline).

Таким образом, из X + (X + 40) мы переходим к X*2 + 40. Здесь X*2 это и есть ἀριθμοὶ δύο – “арифмосы” “дважды” (δύο; вообще, это, пожалуй, максимально знакомое русскоязычному читателю древнегреческое слово: буквально, “два”, даже читается едва ли не более похоже, чем английский вариант того же слова – two; и можно было бы перевести как “дуо-арифмос”, но это, конечно, не совсем так). После “двух арифмосов” и “40 единиц” подчёркивается, что всего дано 100. То есть, сумма должна быть равна сотне единиц (μονάδες ρ̅).

Итак, добрались до X*2 + 40, и 100 – в сумме. Читаем дальше.

Написано: μονάδες ἄρα ρ̅ ἴσαι εἰσὶν ἀριθμοῖς δυσὶ μονάσι μ̅ . Дословный перевод: “единиц, таким образом, сто (100), равны неизвестным двум (и) единицам 40”. Или более естественно: “Таким образом, 100 равно двум неизвестным плюс 40”. То есть, здесь записано: 100 == X*2 + 40.

Задача полностью сформулирована в конкретных числах. Заметьте, что сделанно это с объяснением шагов и преобразований. То есть, что получаем сейчас, если современным языком: “Разность чисел 40, сумма 100; найти числа; запишем формулу X + (X + 40) == 100; следовательно, 2X + 40 == 100”. Совсем простая задача для начальной школы. Как я уже отметил, далеко не все задачи в “Арифметике” Диофанта столь же простые. Далее, на манускрипте, начинается решение. Смотрим.

В современной типографике: καὶ ἀπὸ ὁμοίων ὅμοια, ἀφαιρῶ ἀπὸ τῶν ρ̄ μονάδου μ̄. Перевод: “И из подобного подобное, вычитаю из 100 единиц 40”. К этому фрагменту встречается дополнение, которого нет в рассматриваемом манускрипте Vat.gr.191. В дополнении сказано, что 40 нужно вычитать и из части с удвоенной неизвестной. Скорее всего, у Диофанта достаточным объяснением является вводный фрагмент: “и из подобного подобное”. Этот фрагмент означает, что “единицы” (монады, μοναδες) вычитаются из “единиц”, а неизвестные (арифмос) – остаются. В современных обозначениях: (X*2 + 40) – 40 == 100 – 40.

Текст: λοιποὶ ἀριθμοὶ δύο ἴσοι μονάσιν ξ̄, ἕκαστος ἄρα γίνεσται ἀριθμὸς μονὰδων λ̄. Что дословно означает: “Остаток – неизвестных две равны единицам 60, каждая, таким образом, выходит неизвестная [в] единиц 30”. И здесь имеется в виду то, сколько именно единиц в каждой неизвестной “помещается”. На современном языке, первый шаг (левая часть, до 60): X*2 == 60. Число 60 – это буква кси с чертой (ξ̄). Следующий шаг: X == 60/2 == 30. Число 30 – это лямбда с чертой (λ̄)

Финальный фрагмент.

Это уже ответ. Написано: ἐπὶ τὰσ ὑποστάσεις· ἔσται ὁ μὲν ἐλάσσων μονάδων τριάκοντα. ὁ δὲ μείζων μονάδου ο̄. καὶ ἡ ἀπόδειξις φανερά. Перевод: “В действительности: стало же меньшее единиц тридцать, да большее единиц 70. И продемонстрированное очевидно”. “В действительности” (в “иопстаси”, потому что ὑποστάσεις) тут надо читать как “окончательный результат”, то есть, числа ответа: 30 и 70 (ο̄).

А заключительный типовой оборот – “καὶ ἡ ἀπόδειξις φανερά”, – это некий аналог “что и требовалось доказать”, но только в том смысле, что, благодаря продемонстрированному, стал очевидным полученный ответ.

В июле 2026 года записок вышло не так много, но всё же набралось пять, которые можно отметить отдельно:

• Буквы, омоглифы и современные LLM
• Техническое: безопасная автоматизация ACME в открытых веб-сервисах
• Пароли и постквантовая стойкость
• Монеты постоянной ширины и гагара на канадском долларе
• Короткоживущие сертификаты и штатный их отзыв