Постквантові докази для автономних агентів у Quantova Virtual Machine

Анотація

Автономні агенти та агенти суперінтелекту нині здійснюють платежі, ухвалюють рішення та подають документи від імені компаній у сферах банківської діяльності, державного управління, охорони здоров'я та фінансів. Записи про те, що зробили ці агенти, зберігаються в операторів, чию поведінку ці записи описують. Такі записи може переписати їхній зберігач, а якщо їх узагалі підписано, то за допомогою ECDSA, EdDSA або RSA, підписи яких алгоритм Шора дає змогу квантовому комп'ютеру підробити за поліноміальний час.

Qstamp є відкритим SDK і набором смарт-контрактів Quanta у Quantova Virtual Machine (QVM), які перетворюють записи агентів на довговічні докази, що їх може перевірити будь-хто, тоді як самі записи залишаються конфіденційними в оператора. Кожен запис зводиться до дайджесту SHA3 256 і пов'язується зі свіжою 256-бітовою сіллю. Отримані листи об'єднуються в хеш-дерево RFC 9162, що містить до 2²⁰ листів, а дерево фіксується криптографічним зобов'язанням у вигляді одного 32-байтового значення з розділенням доменів, яке пов'язує ланцюг, контракт, підписанта, вид запису та розмір пакета. Криптографічне зобов'язання закріплюється атестованим смарт-контрактом Quanta в транзакції, підписаній ML DSA 65, і набуває остаточності завдяки комітету валідаторів, який підписує кожен блок за допомогою ML DSA 65 від генезис-блоку.

Ми визначаємо гру з підробки доказів і доводимо, що перевага будь-якого класичного чи квантового супротивника обмежена перевагами щодо знаходження колізій і других прообразів для SHA3 256, q-кратною перевагою EUF-CMA щодо ML DSA 65 та ймовірністю збою консенсусу. Ми точно визначаємо, що доводить квитанція і чого вона не доводить, описуємо, як контракти компілюються, атестуються та розгортаються, наводимо процедуру перевірки, придатну для виконання ухвал судів і розпоряджень регуляторів, із розібраним прикладом із тестової мережі Quantova, а також співвідносимо конструкцію з обов'язками щодо ведення записів у Європейському Союзі, Сполученому Королівстві, Сполучених Штатах, Японії, Кореї та Гонконгу.

Ключові слова

1. Вступ і стислий виклад внеску

Програмні агенти, побудовані на великих моделях, нині викликають інструменти, переказують кошти, схвалюють кредити та створюють контент від імені людей і установ. Коли таку дію згодом оскаржують, питання, яке постає перед судом, наглядовим органом або страховиком, має фактичний характер. Що зробив агент, на основі якої моделі та політики і коли? Відповідь майже завжди беруть із записів, які веде оператор агента, тобто та сама сторона, чия поведінка ставиться під сумнів.

Звідси випливають дві вразливості. Перша стосується зберігання. Запис, що зберігається в базі даних під адміністративним контролем оператора, може бути змінений оператором, і ніщо в самому записі не виявляє цієї зміни. Друга стосується довговічності. Якщо записи захищено криптографічно, то захистом є цифровий підпис на основі ECDSA, EdDSA або RSA, а опубліковані оцінки ресурсів свідчать, що відмовостійкий квантовий комп'ютер достатнього розміру підробляв би такі підписи за години або дні [10, 11, 8]. Багато записів необхідно зберігати від шести до десяти років [37, 35], що є тривалим строком порівняно з невизначеністю щодо того, коли така машина може з'явитися [13].

Qstamp усуває обидві вразливості однією конструкцією. Кожен запис у межах периметра оператора зводиться до криптографічного зобов'язання SHA3 256 із сіллю. Пакет, що містить до 2²⁰ криптографічних зобов'язань, агрегується в хеш-дерево, і одне 32-байтове значення, яке пов'язує дерево з його ланцюгом, контрактом, підписантом, видом і розміром, закріплюється через смарт-контракт Quanta у Quantova Virtual Machine. Кожен підпис, від якого залежить це закріплення, від акаунта, що його подає, до комітету, що забезпечує його остаточність, є підписом ML DSA 65 [24], і так було від генезис-блоку мережі. Запис ніколи не залишає оператора, і будь-яка сторона, що володіє записом і його квитанцією, може згодом перевірити його без довіри до оператора або Quantova Inc.

Внесок цієї статті полягає в такому.

1. Формальна модель оператора як внутрішнього супротивника та квантового супротивника щодо класичних підписів, а також предикат, що відображає вимоги чинного регулювання щодо ведення записів (розділ 2 і розділ 3).
2. Повна специфікація конструкції Qstamp точно в тому вигляді, в якому її реалізовано у випуску SDK 0.1.4, включно з кодуваннями, алгоритмами засвідчення та перевірки і тризначним результатом перевірки (розділ 5).
3. Зведення, яке доводить, що підробка доказів щодо Qstamp обмежена стійкістю SHA3 256 до колізій і других прообразів, неможливістю підробки ML DSA 65 та безпекою консенсусу, разом із властивостями зв'язування, приховування та живучості і конкретними класичними та квантовими оцінками (розділ 6).
4. Точне формулювання того, що доводить квитанція і чого вона не доводить для автономних агентів (розділ 7), а також процедура перевірки для виконання ухвал судів і розпоряджень регуляторів, проілюстрована реальним запуском у тестовій мережі (розділ 8).
5. Співвіднесення правових обов'язків із забезпечуваними формальними властивостями та їхніми межами (розділ 9), аналіз того, чому ці властивості потребують постквантового рівня 1 з атестованим кодом контрактів (розділ 10), а також виміряні вартість і затримка (розділ 11).

Стаття описує лише те, що функціонує на дату версії 1.0. Конструкція працює в тестовій мережі Quantova, квитанції якої не мають доказової сили. Промислове використання здійснюватиметься в основній мережі Quantova після її запуску. Заплановані функції позначено як такі в підрозділі 6.7 і розділі 12.

2. Математичне формулювання проблеми

Усюди далі H позначає SHA3 256 [22], ‖ позначає конкатенацію байтів, λ позначає параметр безпеки, а алгоритм називається ефективним, якщо час його роботи є поліноміальним від λ на класичному комп'ютері (PPT) або на квантовому комп'ютері (QPT).

2.1 Записи під контролем оператора та внутрішній супротивник

Підписи, обчислені O, цього не змінюють. Якщо кожен елемент містить σ_j = Sign(sk_O, e_j), то O, який володіє sk_O, обчислює дійсний σ′ для будь-якої заміни e′. Підпис зберігача автентифікує походження перед третіми сторонами, але нічого не говорить про цілісність щодо самого зберігача. Цілісність щодо O потребує свідка W, тобто сторони або системи, стан якої O не може змінити, що фіксує значення, отримане з Λ, до t_a. У сучасній практиці впевненість V у стані W ґрунтується на підписах W, майже завжди ECDSA над secp256k1 або P 256 [26, 29], Ed25519 [30] або RSA, або взагалі не ґрунтується на жодному підписі, якщо свідком є внутрішня система оператора.

2.2 Алгоритм Shor та його опублікована вартість

2.2.1 Зведення до знаходження порядку

Нехай N є непарним складеним цілим числом, яке не є степенем простого числа, і нехай a вибирається рівномірно з групи оборотних елементів за модулем N. Порядком a є

Якщо r парне і a^r/2 ≢ −1 (mod N), то N ділить добуток (a^r/2 − 1)(a^r/2 + 1), але не ділить жодного з множників, тому

є нетривіальним дільником. Для N, що має щонайменше два різні непарні прості дільники, ця подія має ймовірність не менше половини щодо вибору a [2, 12]. Отже, факторизація зводиться за класичний поліноміальний час до обчислення порядків, а внеском Shor є квантовий алгоритм для останнього [1, 2].

2.2.2 Квантове перетворення Фур'є

Виберемо Q = 2^ℓ так, щоб N² ≤ Q < 2N². Регістр з ℓ кубітів переводиться в рівномірну суперпозицію, і відображення x ↦ a^x mod N оборотно обчислюється в другий регістр,

Квантове перетворення Фур'є над ℤ_Q діє на перший регістр як

і точно реалізується за допомогою O(ℓ²) одно- та двокубітових вентилів. Оскільки другий регістр є періодичним за x з періодом r, вимірювання першого регістра після перетворення з імовірністю Ω(1/log log N) повертає значення y, таке що

для деякого цілого s, взаємно простого з r. За теоремою Legendre s/r тоді є підхідним дробом розкладу y/Q у ланцюговий дріб, що дає змогу отримати r класичними засобами. У вартості домінує модульне піднесення до степеня, що потребує O(ℓ³) вентилів за шкільної арифметики.

2.2.3 Дискретні логарифми та еліптичні криві

Нехай ⟨P⟩ є циклічною групою простого порядку q і нехай Q′ = dP є відкритим ключем. Функція

є сталою точно на суміжних класах підгрупи L. Дворегістрове перетворення Фур'є над ℤ_q² із подальшим вимірюванням дає (u, v) з v ≡ ud (mod q), отже, d = v·u⁻¹ mod q щоразу, коли u ≠ 0 [2]. Для групи еліптичної кривої груповий закон обчислюється оборотно за допомогою арифметики над базовим полем [9]. Roetteler, Naehrig, Svore і Lauter наводять конкретну схему для кривих над простими полями бітової довжини n [8], яка використовує

і кількість вентилів Toffoli порядку 10¹¹ для n = 256. Ця оцінка стосується secp256k1 і P 256, на яких ґрунтується більшість розгортань ECDSA, а з незначними змінами також 255-бітової кривої Ed25519. Це логічні кубіти. Відмовостійка реалізація збільшує фізичну кількість на величину накладних витрат коду виправлення помилок.

2.2.4 Оцінки ресурсів для RSA 2048

Для RSA Gidney і Ekerå у 2019 році оцінили, що 2048-бітовий модуль можна факторизувати приблизно за 8 годин за допомогою 20 мільйонів зашумлених кубітів за припущення, що ймовірність помилки фізичного вентиля становить 10⁻³, тривалість циклу поверхневого коду становить одну мікросекунду, а час реакції системи керування становить десять мікросекунд [10]. У 2025 році Gidney переглянув цю оцінку до менш ніж одного мільйона зашумлених кубітів і менш ніж одного тижня роботи за тих самих припущень щодо апаратного забезпечення [11].

2.3 Наслідки для підписів, реєстрів і журналів

Доказовий наслідок має ретроактивний характер. Нехай елемент e підписано в момент t_c під pk, і нехай t_q є першим моментом, коли супротивник може виконати A_Shor. У будь-який момент T ≥ t_q супротивник створює (e′, σ′) з Verify(pk, e′, σ′) = 1. Верифікатор у момент T має дві пари, які обидві проходять перевірку, і перевірка підпису не дає жодної інформації про те, яка з них існувала в момент t_c. Супротивнику потрібен лише pk, який є публічним і в реєстрах публікується разом із першою транзакцією акаунта. Отже, відкриті ключі та підписані записи можна зібрати зараз і підробити пізніше. Якщо x є періодом, протягом якого докази мають залишатися надійними, y є часом, потрібним для їх міграції, а z є часом до t_q, то умова Mosca [13]

визначає, коли докази стають уразливими. Строки зберігання є тривалими. Записи брокерів-дилерів відповідно до Rule 17a 4 зберігаються до шести років [37], а технічна документація систем ШІ високого ризику протягом десяти років після введення системи в обіг [35].

Платформи смарт-контрактів, що нині працюють у промисловій експлуатації, авторизують транзакції за допомогою ECDSA або EdDSA. На такій платформі твердження про те, що акаунт авторизував транзакцію, підтверджується лише класичним підписом, і після t_q будь-який акаунт, відкритий ключ якого відомий, можна змусити підписати що завгодно. Чи залишається порядок минулих блоків надійним, залежить від того, як верифікатор дізнається канонічну історію. Учасник, який безперервно стежив за ланцюгом, зберігає свої знання. Якщо сам консенсус автентифікується класичними підписами, верифікатор, який реконструює історію після t_q лише на підставі підписів, як це зробив би суд або аудитор, не може відрізнити канонічну історію від альтернативної, підписаної відновленими ключами. Якщо впорядкування забезпечується доказом роботи, впорядкування зберігає безпеку на основі хешування, але авторизація кожної транзакції залишається класичною. Ламається саме рівень підписів.

Хеш-функції послаблюються, але не зламуються. Алгоритм Grover знаходить прообраз n-бітової функції за O(2^n/2) обчислень [3], і це оптимально для загального пошуку [4]. Алгоритм Brassard, Høyer і Tapp знаходить колізії за O(2^n/3) обчислень за наявності квантово доступної пам'яті такого самого розміру [5], що знову оптимально для загальних функцій [6]. Bernstein показує, що з урахуванням вартості цієї пам'яті квантовий пошук колізій не дешевший за класичний паралельний пошук колізій, вартість якого становить приблизно 2^n/2 [7]. Для n = 256 запаси становлять щонайменше 2⁸⁵ у найсприятливішій для атакувальника моделі та приблизно 2¹²⁸ за реалістичної вартості. Ця асиметрія між підписами та хешами є основою конструкції, викладеної в розділі 5.

2.3.1 Класичні примітиви в інфраструктурі агентів

Інфраструктура, за допомогою якої сьогодні ідентифікують, авторизують і перевіряють агентів, ґрунтується на невеликому наборі примітивів з відкритим ключем. У таблиці для кожного з них зазначено задачу, на якій він ґрунтується, і наслідки застосування алгоритму Shor.

Симетричні примітиви поводяться інакше. HMAC і сімейство SHA2 не зазнають впливу алгоритму Shor і лише послаблюються алгоритмом Grover, тому HMAC з 256-бітовим ключем зберігає приблизно 128 бітів безпеки щодо пошуку ключа. Проте код автентифікації повідомлення нічого не доводить третій стороні. Будь-хто, хто володіє ключем, може повторно обчислити дійсний тег для будь-якого зміненого елемента, а в журналі аудиту власником ключа є оператор, тому спостереження 1 застосовується без змін. Те саме стосується хеш-ланцюга, який веде оператор без зовнішнього закріплення і який оператор може повторно обчислити з будь-якої зміненої точки.

2.4 Регуляторна прогалина

У різних юрисдикціях норми вимагають, щоб певні записи створювалися, зберігалися протягом визначених строків і були захищені від змін або зберігалися так, щоб зміни можна було виявити. Регламент ЄС про штучний інтелект (AI Act) вимагає, щоб системи ШІ високого ризику уможливлювали автоматичну реєстрацію подій протягом усього строку їх функціонування (стаття 12), а також вимагає від постачальників і користувачів зберігати ці журнали протягом строку, відповідного цільовому призначенню, але не менше шести місяців (стаття 19 і стаття 26(6)) [35]. Поправка eIDAS 2 надає правове визнання електронним реєстрам і встановлює презумпцію цілісності та хронологічного порядку для кваліфікованих електронних реєстрів (статті 45h і 45i) [36]. SEC Rule 17a 4 вимагає від брокерів-дилерів зберігати електронні записи або з повним журналом аудиту з позначками часу, або у формі, що не допускає перезапису та стирання [37]. Стаття 5(1)(f) UK GDPR вимагає належної безпеки персональних даних, зокрема захисту від несанкціонованої обробки та випадкової втрати або пошкодження [38]. Японський Закон про ведення електронних бухгалтерських книг вимагає заходів, що забезпечують автентичність електронних записів, як-от позначки часу або системи, які фіксують виправлення та видалення [39]. Заходи безпеки, передбачені статтею 29 Закону Кореї про захист персональної інформації, включають ведення записів про доступ і їх захист від підробки та змін [40]. Принцип захисту даних 4 гонконзького Ордонансу про персональні дані (приватність) (Personal Data (Privacy) Ordinance) вимагає від користувачів даних вживати всіх практично можливих заходів для захисту персональних даних від несанкціонованого або випадкового доступу, обробки, стирання, втрати чи використання [41].

Той самий горизонт нині регулюється вимогами щодо постквантової міграції. NIST IR 8547 у своєму першому публічному проєкті пропонує визнати застарілими після 2030 року квантово вразливі алгоритми з відкритим ключем на рівні безпеки 112 бітів і заборонити після 2035 року всі квантово вразливі алгоритми з відкритим ключем [27]. Executive Order 14412 зобов'язує федеральні системи Сполучених Штатів запровадити постквантове встановлення ключів до 31 грудня 2030 року та постквантові цифрові підписи до 31 грудня 2031 року [28]. Отже, записи, створені сьогодні, перевірятимуться в межах строків їх зберігання в той час, коли підписи, що їх захищають, буде офіційно заборонено.

Нормативні акти явно встановлюють Ret через строки зберігання і встановлюють Int у таких термінах, як захист від змін або підробки, сховище без можливості перезапису або журнали аудиту. Ver і Time випливають із мети нагляду та доказування. Прогалина полягає в тому, що кожен механізм, Int якого ґрунтується на класичному підписі, задовольняє Int лише для 𝒜, обмеженого супротивниками, що діють до t_q. Щоразу, коли t₀ + R > t_q, предикат не виконується протягом решти строку. Qstamp призначений забезпечувати Int, Ver і Time для всіх t у межах строку щодо класичних і квантових супротивників за припущень розділу 3. Ret залишається обов'язком зберігача. Жоден із наведених тут законів не вимагає Qstamp. Закони вимагають властивостей, і в розділі 9 визначено, які з них забезпечує Qstamp.

3. Модель системи та модель загроз

3.1 Сторони

• Оператор O. Експлуатує одного або кількох агентів, зберігає їхні записи та контролює ключ підпису sk_S, відкритий ключ ML DSA 65 якого визначає адресу в ланцюзі S. O використовує Qstamp SDK.
• Верифікатор V. Суд, регулятор, аудитор, страховик або контрагент. V володіє лише публічними параметрами, а саме хешем генезису G ланцюга, адресою C офіційного контракту Qstamp і опублікованим набором валідаторів, а також усім, що надає O.
• Мережа. Ланцюг Quantova, що складається з QVM, комітету валідаторів 𝒱, який забезпечує остаточність блоків, а також кінцевих точок RPC і оглядача блоків, які надають дані ланцюга.
• Супротивник A. Будь-яка сторона, яка прагне, щоб V прийняв хибне твердження щодо запису.

3.2 Припущення

3.3 Класи супротивників

Класичний супротивник є PPT. Квантовий супротивник є QPT, може виконувати алгоритми Shor і Grover в офлайн-режимі та має квантовий доступ до H, якщо використовується модель випадкового оракула [16]. Обидва класи можуть скомпрометувати оператора після моменту t*, що моделює інсайдера, який згодом бажає переписати історію, або пізнішу компрометацію sk_S. Обидва можуть контролювати будь-які інші акаунти, компрометувати членів комітету в межах обмеження T3, затримувати, переупорядковувати або відкидати мережеві повідомлення, а також експлуатувати власні кінцеві точки RPC. Припускається, що чесний оператор коректно здійснює засвідчення до t*.

Три питання перебувають поза межами моделі та наводяться для того, щоб їх не сприймали як гарантії. Запис, який був хибним на момент засвідчення, залишається хибним, оскільки Qstamp фіксує зміст і не оцінює його. Супротивник, який володіє sk_S до засвідчення запису, може здійснити засвідчення від імені S, що є питанням зберігання ключів. Доступність запису та його квитанції є відповідальністю зберігача, оскільки втрата солі унеможливлює доведення відповідного включення.

4. Платформа Quantova

У цьому розділі описано компоненти, на які покладається Qstamp, у тому вигляді, в якому вони функціонують на дату цієї статті.

4.1 Quanta, мова смарт-контрактів

Quanta є мовою контрактів ланцюга Quantova. Контракт Quanta компілюється в контейнер QVM. Повноваження всередині контракту випливають лише з перевірених підписів. Викликачем точки входу є перевірений підписант транзакції, а контракт може перевіряти додаткові підписи ML DSA над підписаними розпорядженнями за допомогою інструкції QVM VERIFY_ML. Кожна така перевірка використовує рядок контексту FIPS 204 QVM/contract/v1, який FIPS 204 включає до підписуваного повідомлення як

тому підпис, створений для розпорядження контракту, неможливо подати як підпис у будь-якому іншому контексті [24]. Відкритий контракт Qstamp є наведеним нижче вихідним кодом Quanta, який не зберігає жодного стану, жодних коштів і не має власника.

Шаблони емітента та ради додають підписані розпорядження, що містять nonce, який зберігається контрактом, кінцевий строк і доменне значення для кожного розгортання, тож розпорядження неможливо відтворити повторно, використати із запізненням або використати в іншому розгортанні.

4.2 Атестований компілятор

Контейнер c ідентифікується як id(c) = H(c). Ланцюг допускає розгортання, лише якщо ідентифікатор має підпис ML DSA 65, створений ключем походження компілятора,

Підпис встановлює, що розгорнутий контейнер створено атестованим компілятором. Ідентичність перевіреному вихідному коду потім встановлюється шляхом відтворення. Рецензент компілює опублікований вихідний код, побайтово порівнює отриманий контейнер із розгорнутим і таким чином підтверджує, що код за адресою C є тим кодом, який було перевірено. Опублікований вихідний код відкритого контракту Qstamp побайтово компілюється в контракт, розгорнутий у тестовій мережі. Гарантія передбачає безпечне зберігання ключа походження компанією Quantova Inc. Лише для властивості ідентичності коду це є припущенням про довіру, додатковим до припущень від T1 до T5.

4.3 Quantova Virtual Machine і рівень виконання

QVM є регістровою машиною з обліком ресурсів і нативними інструкціями для перевірки ML DSA і SLH DSA [25], хешування та хеш-дерев. Перед виконанням QVM записує перевіреного відправника транзакції в пам'ять контракту як caller, тому на зафіксованого підписанта неможливо вплинути через дані виклику. Виконання є атомарним. Якщо S є станом, tx є транзакцією, а m є її лімітом обліку,

де E є списком згенерованих подій. Події та зміни стану фіксуються лише в разі успіху, а події включаються до кореня подій заголовка блоку. Отже, транзакція, що набула остаточності, без своєї події нічого не доводить щодо засвідчення, і перевірка в розділі 5 потребує наявності події.

4.4 Консенсус і остаточність

Кожен акаунт, кожна транзакція та кожен сертифікат остаточності в ланцюзі Quantova підписуються за допомогою ML DSA 65 від генезис-блоку, а SLH DSA доступна як альтернативна схема акаунтів, описана вище. Адреса є 32-байтовим значенням, отриманим з відкритого ключа ML DSA 65. Остаточність блоків забезпечує вибраний комітет, сертифікат якого містить підписи ML DSA 65, що досягають порогу остаточності, і остаточність досягається приблизно за 0,2 секунди. Час блоку пропонується в цілих секундах. За T4 прийнятий блок B з батьківським блоком P задовольняє умову

тому час блоку ніколи не зменшується і не може випереджати годинники чесних учасників більш ніж на 15 секунд.

4.5 Комісії

Виконання обліковується, і комісія за виклик, який споживає m одиниць обліку, становить

із поверненням невикористаного резерву. Виклик stamp має дані виклику фіксованої довжини та генерує одну подію фіксованої довжини, тому його комісія не залежить від розміру пакета N. У тестовій мережі одне засвідчення коштує 0,005 TQTOV, тобто 5000 quon, незалежно від N. TQTOV є одиницями тестової мережі без грошової вартості.

5. Конструкція Qstamp

5.1 Позначення

5.2 Листи, дерево та криптографічне зобов'язання

Для запису r_i з дайджестом d_i = D_alg(r_i) листом є

тобто обчислення H на рівно 1 + 14 + 1 + 32 + 32 = 80 байтах. Листи утворюють дерево згідно з RFC 9162, розділ 2.1 [31], внутрішніми вузлами якого є

тобто обчислення H на рівно 65 байтах.

Криптографічним зобов'язанням є

тобто обчислення H на рівно 1 + 14 + 32 + 32 + 32 + 8 + 8 + 32 = 159 байтах. Три ролі розділено першим байтом і довжинами, і ця властивість використовується в лемі 1. Конструкція слідує хеш-дереву Merkle [18] та ідеї зв'язування Haber і Stornetta [19] із розділенням доменів RFC 9162 і явним зв'язуванням розміру та контексту.

5.3 Закріплення

K розділяється на дві 16-байтові половини (hi, lo) і подається від S у виклику офіційного контракту C,

Дані виклику мають фіксовану довжину і складаються з 4-байтового селектора, 120 байтів контексту хоста, 32-байтового криптографічного зобов'язання та 8-байтового виду. Дані події мають 72 байти. Оскільки контракт не зберігає стану, може співіснувати будь-яка кількість засвідчень будь-якого криптографічного зобов'язання, і жодне засвідчення не може перешкодити фіксації іншого.

5.4 Квитанція

Кожен запис отримує власну квитанцію, кортеж

де fmt = qstamp-receipt/1, ідентифікатор назви ланцюга id і генезис G, контракт C, вид k у вигляді десяткового рядка, алгоритм дайджесту, дайджест і сіль, позиція, розмір пакета та шлях включення, корінь дерева, а також транзакція закріплення, висота блоку h, ідентифікатор блоку B, час блоку t у секундах від 1970 року та підписант S. Квитанція не містить жодної частини запису. Проте вона містить дайджест і сіль, що має значення для підрозділу 6.5.

5.5 Алгоритми

Перевірка повертає один із трьох результатів. Дійсна означає, що всі перевірки пройдено. Недійсна означає, що щонайменше одна суттєва перевірка не пройшла, включно з випадком, коли не було надано жодного запису або дайджесту. Невизначено означає, що кожна непройдена перевірка була збоєм передавання, як-от недоступна кінцева точка або обрізаний список подій. Результат «невизначено» ніколи не повідомляється як «дійсна». Перевірки мають назви format, contract, content, inclusion, chain, transaction, event і block, усього вісім.

$ npm install @quantovainc/qstamp
added 2 packages

$ npx @quantovainc/qstamp --version
0.1.4

$ openssl rand -hex 32 > signer.key && chmod 600 signer.key
$ node account.js
address  Q1NUR6ETECQXEVE77TJ9YPZ6WAWYMT45WCJANV5J43X93SF79DWE0S0D572X
status   registered, ready to stamp

{
  "evaluation": {"approved_by": "Model Risk Committee", "auc": 0.871},
  "model": "risk-model 3.2.1",
  "time": "2026-10-09T09:39:27.273Z",
  "training_data": "dataset manifest 2026-09-30",
  "weights_sha3": "f01483b8e6269760c5c2e2025875b6e5d1b16402443e9a98d73e0a43156bf17b"
}

const qstamp = require('@quantovainc/qstamp');
const batch = [];

agent.on('action', (action) => {
  const bytes = Buffer.from(canonicalJson(action));
  log.write(bytes);
  batch.push({ digest: qstamp.digestBytes(bytes) });
});

setInterval(async () => {
  const records = batch.splice(0);
  if (records.length === 0) return;
  const receipts = await qstamp.stamp({
    seed, index: 0, kind: 'ai_agent_action', records,
    onPending: savePending,
  });
  receipts.forEach(storeBesideAction);
}, 60000);

{
  "agent": "credit-decision-agent-07",
  "amount_usd": 125000,
  "applicant": "APP-54a49c823275",
  "decision": "approve",
  "human_review": false,
  "model": "risk-model 3.2.1",
  "operator": "Example Bank plc",
  "policy": "retail-lending-policy 2026-10",
  "reasons": ["score_above_threshold"],
  "risk_score": 645,
  "time": "2026-10-09T09:39:25.132Z",
  "tool": "credit_bureau.lookup"
}

$ npx @quantovainc/qstamp hash action-04.json
  action-04.json

$ npx @quantovainc/qstamp verify action-04.json.qstamp.json --file action-04.json
pass format · pass contract · pass content · pass inclusion
pass chain · pass transaction · pass event · pass block
VALID  stamped no later than 2026-10-09T09:39:25Z in block 2011753

$ npx @quantovainc/qstamp verify action-04.json.qstamp.json --file altered.json
FAIL content  the content does not match the fingerprint in the receipt
INVALID

6. Аналіз безпеки

6.1 Гра підробки доказів

Гра охоплює інсайдера, який переписує історію заднім числом, оскільки A отримує sk_S і все одно має прив'язати r′ до закріплення, зробленого до t*. Вона охоплює стороннього суб'єкта, який підмінює зміст, і третю сторону, яка намагається скомпрометувати S записом, який S ніколи не засвідчував. Нове засвідчення r′ після t* не є підробкою, оскільки його квитанція зазначає пізніший час.

6.2 Розділення доменів

Без префіксів ролей внутрішній вузол можна було б подати як лист, що є класичною неоднозначністю другого прообразу дерев Merkle без префіксів, яку усуває RFC 9162 [31]. Без u64(N) корінь не визначав би форми свого дерева, і один шлях міг би проходити перевірку за кількох розмірів.

6.3 Основна теорема

Схема доведення. Нехай A перемагає з виходом (r′, ρ′), де ρ′ зазначає alg′, d′, s′, позицію i, розмір N′, шлях π′, root′, вид k′, транзакцію tx, висоту h, час t ≤ t* і підписанта S. Успішність усіх восьми перевірок дає такі факти. G і C є офіційними значеннями. D(r′) = d′. RootFromPath(L′, i, N′, π′) = root′, де L′ є листом для (alg′, d′, s′). За T5 блок, що набув остаточності на висоті h, містить tx від S до C і подію C з даними S ‖ K′ ‖ u64(k′), де K′ = Commit(G, C, S, k′, N′, root′). Розіб'ємо подію перемоги на випадки.

1. Збій консенсусу. Блок, повідомлений на висоті h, не є єдиним блоком, що набув остаточності на цій висоті. Це суперечить T3, за винятком імовірності Adv_consensus, після виключення підроблених підписів комітету, які належать до наступного випадку.
2. Підробка підпису. Канонічний блок на висоті h містить транзакцію від S, яку претендент не підписував до t*, або підпис комітету, якого не створював жоден чесний член. До t* чесні засвідчення є саме запитами на підпис, тому B₃ вгадує, який із q ключів підроблено, вбудовує туди свій ключ виклику та виводить підробку. Це коштує не більше q · Adv^EUF-CMA.
3. Чесне закріплення. В іншому разі подію згенеровано чесним засвідченням із пакетом (r₀, …, r_N−1), солями s_i, видом k і криптографічним зобов'язанням K, оскільки кожна транзакція від S до t* є чесною, а дані події зазначають S. Зіставлення подій дає K′ = K і k′ = k. За лемою 1 або (N′, root′) = (N, root), або B₁ чи B₂ виводить колізію двох 159-байтових рядків.
4. Те саме дерево. За однакових розміру та кореня алгоритм 3 повторно обчислює корінь з L′ уздовж шляху, форма якого залежить лише від (i, N). Пройдемо від кореня до листа. На першому рівні, на якому входи чесного та поданого вузлів відрізняються, обидва входи хешуються в однаковий вихід, що за лемою 1 є колізією двох 65-байтових рядків. Якщо жоден рівень не відрізняється, то L′ = L_i.
5. Той самий лист. За лемою 1 або (alg′, d′, s′) = (alg, d_i, s_i), або два 80-байтові входи утворюють колізію.
6. Той самий дайджест. Тоді D(r′) = d_i = D(r_i) з r′ ≠ r_i, оскільки A перемагає, що є колізією D = SHA3 256.

Залишається віднести кожну колізію, знайдену у випадках від 3 до 6, до B₁ або B₂. Якщо чесний вхід колізійної пари є функцією значень, вибраних лише A, як у разі, коли A вибрав пакет, а колізійний вхід не містить свіжої солі, то пара є колізією і виводиться B₁. Якщо чесний вхід містить значення, не вибране A, а саме сіль s_i або запис, наданий чесною стороною, то чесний вхід є ціллю, зафіксованою до того, як A розпочинає пошук, і A знайшов другий вхід з тим самим образом. Це є другим прообразом у сенсі Rogaway і Shrimpton для цілей, вибраних із чесного розподілу [17], і він виводиться B₂. Ці два віднесення не перетинаються, тому оцінка об'єднання за випадками від 1 до 6 дає (22). ∎

Для alg = 2 крок дайджесту у випадку 6 спирається на SHA 256, і оцінка отримує відповідні доданки для SHA 256. Зв'язування потребує лише T1, T2 і T3 у стандартній моделі. Приховування в підрозділі 6.5 використовує модель випадкового оракула [15, 16].

6.4 Зв'язування контексту, повторне відтворення та випередження

Це випливає з леми 1 і має п'ять наслідків. Криптографічне зобов'язання, закріплене в одному ланцюзі, не проходить перевірку щодо іншого, оскільки G відрізняється, і перезапущена мережа з новим генезисом не може перевірити старі квитанції. Квитанція не проходить перевірку щодо іншого контракту, оскільки C відрізняється. Суб'єкт випередження F, який копіює K з транзакції в очікуванні та подає stamp(K, k) зі свого акаунта, отримує подію, що зазначає F, а квитанція, яка зазначає F, проходить перевірку, лише якщо K = Commit(G, C, F, k, N, root), тобто за колізії. Оскільки відкритий контракт не має стану, копія не перешкоджає фіксації початкової транзакції S, тому випередження не викрадає і не блокує засвідчення. Заявлений вид неможливо змінити після закріплення. Розмір пакета є фіксованим, що усуває неоднозначність розміру, властиву голим кореням RFC 9162.

6.5 Приховування

Це застереження є суттєвим. Власник квитанції знає s_i і d_i. Оскільки d_i = D(r_i) не містить солі, власник квитанції може перевірити припущення щодо запису з низькою ентропією, як-от суми або короткого коду, одним обчисленням хешу. Тому квитанції необхідно захищати так само, як записи, які вони описують. Приховування захищає зміст від спостерігачів ланцюга, але не від власників квитанцій.

6.6 Конкретні оцінки

Категорія NIST 3 означає, що злам схеми потребує ресурсів, порівнянних із пошуком ключа блокового шифру з 192-бітовим ключем або більших за них [24]. FIPS 202 зазначає для SHA3 256 стійкість до колізій 128 бітів і стійкість до прообразів і других прообразів 256 бітів щодо класичних атак [22].

6.7 Живучість, невизначеність і довірена кінцева точка

Живучість засвідчення. Засвідчення завершується, коли комітет забезпечує остаточність його транзакції. Якщо остаточність не спостерігається протягом тайм-ауту, алгоритм 1 повертає збережений пакет в очікуванні, який містить солі, криптографічне зобов'язання та ідентифікатор транзакції. Квитанції згодом формуються з цього пакета без повторної оплати. Помилка, що виникла під час подання транзакції, також містить пакет в очікуванні, тому солі ніколи не втрачаються через збій мережі.

Довірена кінцева точка випуску 0.1. Перевірки з 1 по 4 виконуються на машині верифікатора і не залежать від жодної сторонньої сторони. На перевірки chain, transaction, event і block відповідають кінцеві точки RPC, тому потрібне T5. Кінцева точка, що експлуатується недобросовісно, могла б повідомити про закріплення, якого не існує. Випуск 0.1 пом'якшує цей ризик завдяки використанню за замовчуванням офіційної кінцевої точки, перевірці того, що кожна кінцева точка обслуговує ланцюг, зазначений у квитанції, вимозі узгодженості всіх опитаних кінцевих точок і повідомленню про те, які кінцеві точки було опитано. Без T5 (22) отримує доданок Adv_endpoint, що дорівнює ймовірності того, що всі опитані кінцеві точки узгоджено надають неправдиві дані. T5 також охоплює канал до кожної кінцевої точки. Відповіді передаються через TLS, що є транспортною безпекою поза протоколом Quantova і може використовувати класичний обмін ключами та сертифікати, тому супротивник, здатний видати себе за кінцеву точку на транспортному рівні, враховується в тому самому доданку.

Заплановані офлайн-докази остаточності. Майбутній випуск міститиме в кожній квитанції заголовок блоку висоти h, сертифікат остаточності комітету та доказ включення події Stamped щодо кореня подій заголовка. Тоді перевірка потребуватиме лише квитанції, запису та опублікованого набору валідаторів. Доданок кінцевої точки зникає, а перевірки ланцюга зводяться до перевірки ML DSA 65 за T2 і T3, тому (22) справджується без T5.

7. Застосування до автономних агентів та агентів суперінтелекту

7.1 Канонічні записи дій

Дія a агента є доказом лише через байтове кодування canon(a), а дайджестом є d = D(canon(a)). Кодування має бути зафіксоване та версіоноване оператором, оскільки дві серіалізації того самого змісту дають різні дайджести. Зміна серіалізації призводить до хибного висновку invalid, але ніколи до хибного висновку valid. Цій потребі відповідає канонічна форма JSON з лексикографічно відсортованими ключами та без незначущих пробілів, як-от схема RFC 8785 [32]. SDK хешує рівно ті байти, які йому передано, і не нав'язує серіалізації. Корисний запис дії зазначає агента, оператора, модель та її версію, чинну політику, викликаний інструмент, використані вхідні дані, рішення або результат, факт перегляду людиною та час, заявлений агентом.

7.2 Пакетування

Оператор збирає дії протягом вікна Δ або до досягнення певної кількості та засвідчує їх як один пакет. Тоді дія, здійснена в момент τ, має закріплення, блок якого набув остаточності не пізніше τ + Δ + t_fin, де t_fin є затримкою засвідчення. Вартість однієї дії становить fee / N. Суттєві дії, як-от платежі понад встановлений поріг, можна засвідчувати окремо до або після виконання, щоб запис набув остаточності до завершення дії. Хук onPending дає змогу оператору зберігати кожен поданий пакет перед очікуванням остаточності.

7.3 Види записів

Вид є 64-бітовим значенням, яке включено до K і згенеровано в події. Він зазначає, що, за заявою S, містить пакет. Він не є перевіреною класифікацією змісту.

7.4 Паспорти моделей

Паспорт моделі є схемою використання, а не окремим механізмом. Під час випуску оператор засвідчує з видом ai_model запис, який містить перелік дайджестів артефактів моделі, дайджест маніфесту набору даних, засвідченого з видом ai_dataset, і дайджести звітів про оцінювання. Кожен наступний запис дії зазначає версію моделі та дайджест її паспорта, тож квитанція дії веде до квитанції, яка зафіксувала модель, від якої залежала дія.

7.5 Що доводить квитанція і чого вона не доводить

8. Доказова процедура для виконання ухвали суду

Припустімо, що суд або регулятор зобов'язує SI-компанію показати, що зробив її агент у певній справі. Наведена нижче процедура не вимагає від компанії нічого, крім подання документів, а від верифікатора нічого, крім публічних параметрів і обчислень.

1. Подання. Компанія подає запис r і його квитанцію ρ. Ухвала може також вимагати подання правила канонізації, що застосовується до записів цього типу.
2. Повторне обчислення. Верифікатор повторно обчислює d = H(r), лист L з (alg, d, s), корінь з (L, i, N, π) за алгоритмом 3 і K з (G, C, S, k, N, root). Цей крок не потребує доступу до мережі і може бути виконаний за допомогою SDK, команди qstamp verify або незалежної реалізації розділу 5.
3. Закріплення. Використовуючи публічний ланцюг через одну або кілька незалежних кінцевих точок RPC і в оглядачі блоків, верифікатор перевіряє, що транзакцію, зазначену в ρ, було надіслано S до офіційного контракту C і що блок h містить подію Stamped контракту C з даними S ‖ K ‖ u64(k). Оглядач блоків є поданням даних ланцюга, яке дає змогу нетехнічному читачеві підтвердити ті самі факти. Він не є окремим якорем довіри.
4. Остаточність. Верифікатор перевіряє, що транзакція є остаточною і що блок на висоті h має ідентифікатор B і час t.
5. Результат. Якщо всі перевірки пройдено, результатом є valid, і твердження 5 визначає, що саме встановлено. Якщо суттєва перевірка не пройшла, результатом є invalid, і непройдена перевірка вказує, яка ланка не виконується. Якщо до мережі не вдалося звернутися, результатом є indeterminate, і процедура повторюється.

8.1 Розібраний приклад із тестової мережі Quantova

Агент ухвалення кредитних рішень створив наведений нижче запис, серіалізований як канонічний JSON з відсортованими ключами та без незначущих пробілів.

Запис було засвідчено в пакеті з шести записів. Наведені нижче значення взято з цього запуску.

Транзакцію закріплення можна переглянути за адресою https://qvmscan.io/tx/QTX1V53JW528S64SZYD6EDZ563N0PUUA2ARGNQHV4LTJMNH24PQS5VPQTAH8RQ.

Перевірка квитанції щодо запису повернула valid, усі вісім перевірок пройдено.

Потім суму в записі змінили на величину 1000 і повторили перевірку з тією самою квитанцією. Перевірка content не пройшла, і результатом стало invalid. Інші перевірки ця зміна не зачіпає, що є задуманою поведінкою, оскільки висновок зазначає саме ту ланку, яка порушилася. Для ілюстрації заміна 125000 на 126000 дає дайджест

Дві особливості прикладу заслуговують на коментар. По-перше, поле часу всередині запису, 09:39:25.132, є твердженням агента і не засвідчується. Час блоку є цілою секундою, 09:39:25, і збігається із записом за цієї роздільності. По-друге, час, виміряний від подання до спостереження остаточності, становив приблизно 0,7 секунди, що включає інтервал опитування SDK.

9. Відповідність регуляторним вимогам

У таблиці кожен обов'язок співвіднесено з формальною властивістю, яку забезпечує Qstamp, і з межами цієї властивості. Перекази змісту є стислими викладами для орієнтації і не замінюють текстів правових актів [35, 36, 37, 38, 39, 40, 41, 27]. Жоден із наведених законів не вимагає Qstamp. Кожен із них вимагає певних властивостей записів, і Qstamp забезпечує деякі з них.

Кожна організація залишається відповідальною за виконання всіх вимог законів, що до неї застосовуються, і повинна отримати власну юридичну консультацію.

10. Чим вирізняється ця конструкція

Ми стверджуємо, що довговічні докази для агентів потребують одночасно чотирьох властивостей і що класичний ланцюг не може набути першої з них для своєї наявної історії лише шляхом міграції.

1. R1. Постквантова автентифікація всієї історії. Кожен підпис, від якого залежить закріплення, від акаунта, що його подає, до остаточності, є постквантовим аж до генезису, і протокол не приймає жодного класичного підпису, який міг би встановити конкуруючий факт.
2. R2. Незалежний свідок. Закріплення фіксується комітетом, незалежним від зберігача, а не зберігачем чи одним органом.
3. R3. Атестований код. Код, що фіксує закріплення, є доведено тим кодом, який було перевірено, і його неможливо замінити за тією самою адресою.
4. R4. Програмовані повноваження. Інституційні політики, як-от уповноважені емітенти, погодження кількома сторонами та відкликання, виконуються з постквантовою автентифікацією.

Умова твердження 6 описує реальний засіб захисту, який слід викласти неупереджено. Докази можна зберегти шляхом поновлення, за якого старі докази включаються до структури на основі стійкіших примітивів до того, як старі примітиви втратять стійкість, як у поновленні Haber і Stornetta [19] та в Evidence Record Syntax згідно з RFC 4998 [34]. Поновлення має відбутися до t_q, саме має бути перевірюваним і захищає лише те, що було поновлено. Мережі, яка є постквантовою від генезису, немає чого поновлювати у власній історії. Саме в цьому сенсі модернізація класичного ланцюга залишає його попередню історію придатною до підробки, якщо її не поновлено вчасно.

Постквантовий орган позначок часу задовольняє R1, але покладається на один орган і не пропонує програмованих політик. Реєстр без атестованого коду задовольняє R2 і R4, але верифікатор має незалежно перевіряти байт-код за адресою контракту. Таблиця узагальнює типові розгортання кожної категорії станом на 2026 рік. Вона описує категорії, а не названі продукти.

Наскільки нам відомо, на дату цієї статті небагато мереж у промисловій експлуатації поєднували R1, R2, R3 і R4 від генезису. Ми не стверджуємо, що це поєднання притаманне виключно Quantova, і аргументація цього розділу залежить лише від властивостей, а не від того, про яку саме мережу йдеться.

11. Економіка та продуктивність

Згідно з (15) комісія за засвідчення залежить лише від обсягу обліку, спожитого викликом фіксованої довжини, тому одне засвідчення в тестовій мережі коштує 0,005 TQTOV, тобто 5000 quon, для будь-якого N. Амортизована вартість одного запису становить

У ланцюзі кожне засвідчення додає 164 байти даних виклику та 72-байтову подію незалежно від N. Локальна перевірка коштує одного дайджесту запису та не більше ⌈log₂N⌉ + 2 додаткових обчислень SHA3 256 на входах фіксованої довжини. Перевірка в ланцюзі коштує чотирьох запитів до кожної кінцевої точки щодо ідентичності ланцюга, транзакції, подій і блоку.

Під час запуску в тестовій мережі, у якому було отримано приклад розділу 8, час від подання засвідчення до спостереження остаточності становив приблизно 0,7 секунди за остаточності ланцюга приблизно 0,2 секунди. Різниця пояснюється поданням і 400-мілісекундним інтервалом опитування, з яким SDK відстежує остаточність. Чотири засвідчення коштували загалом 0,02 TQTOV, тобто по 0,005 TQTOV кожне. Ці величини є вимірюваннями в тестовій мережі і не є гарантіями продуктивності чи ціни в основній мережі.

12. Обмеження та подальша робота

1. Офлайн-докази остаточності. Випуск 0.1 підтверджує факти ланцюга через кінцеві точки RPC і тому покладається на T5. Вбудовування в кожну квитанцію заголовка блоку, сертифіката остаточності та доказу включення події, як описано в підрозділі 6.7, заплановано, і воно усуне цю залежність.
2. Домен для кожного розгортання в шаблонах. Шаблони емітента та ради відхиляють розпорядження, доменне значення яких відрізняється від доменного значення розгортання. Це значення є 64-бітовим числом, яке вибирає сторона розгортання, і забезпечення його свіжості є операційним обов'язком. Адреса контракту залежить лише від акаунта, що здійснює розгортання, і кількості його транзакцій, тому після перезапуску або в разі розгалуження ланцюга нове розгортання може отримати адресу попереднього, і тоді лише свіже доменне значення запобігає прийняттю розпоряджень, підписаних для попереднього розгортання.
3. SDK поки що не перевіряє відкликання. Шаблон емітента фіксує вилучення криптографічного зобов'язання з кодом причини, але Verify не звертається до цього стану. Квитанція для вилученого криптографічного зобов'язання все одно проходить перевірку як дійсна, і верифікатор, який покладається на вилучення, повинен окремо запитувати контракт емітента.
4. Аудит третьою стороною. SDK і контракти перед публікацією пройшли внутрішню перевірку. Шаблони контрактів опубліковано як приклади, і незалежний аудит кваліфікованою третьою стороною є обов'язковим перед будь-яким їх розгортанням у промисловій експлуатації та рекомендованим перед тим, як покладатися на SDK у промисловій експлуатації.
5. Роздільність часу. Час блоку має роздільність в одну секунду, обмежений зверху припущенням T4, а знизу лише часом батьківського блоку. Квитанції встановлюють існування не пізніше моменту остаточності, а не найраніший час.
6. Повнота. Квитанція доводить включення, а не повноту. Послідовна нумерація та зчеплення пакетів, запропоновані в підрозділі 7.5, є практиками оператора і не забезпечуються контрактом.
7. Статус мережі. Усі результати цієї статті стосуються тестової мережі. Квитанції, створені в ній, не мають доказової сили, а промислове використання здійснюватиметься в основній мережі Quantova після її запуску.

13. Правовий статус цієї статті

Ця стаття є технічною специфікацією та описом Qstamp, що надаються Quantova Inc з інформаційною метою. Сама по собі вона не створює жодних договірних зобов'язань, гарантій, заяв або запевнень і не є юридичною, регуляторною, податковою чи інвестиційною консультацією. Використання Qstamp, Qstamp SDK і шаблонів контрактів Quanta регулюється Умовами використання, ліцензіями, на умовах яких опубліковано програмне забезпечення, і будь-яким договором, укладеним із Quantova Inc, які в разі суперечності мають переважну силу щодо цієї статті. Положення щодо законів і нормативних актів є стислими викладами для орієнтації. Положення щодо майбутніх функцій описують поточні наміри і можуть змінюватися.

Застереження. Кожне твердження цієї статті про те, що Quantova або Qstamp є постквантовими або не покладаються на класичні підписи, стосується протоколу Quantova, тобто підписів на акаунтах, транзакціях і сертифікатах остаточності, атестації коду контрактів і консенсусу. Воно не поширюється на транспортну безпеку поза протоколом, як-от з'єднання TLS, сертифікати та обмін ключами, що використовуються вебсайтами, оглядачем блоків, шлюзами RPC та іншим вебхостингом, які можуть використовувати класичні алгоритми. У випуску 0.1 перевірки ланцюга під час перевірки покладаються на цілісність відповідей, отриманих від кінцевих точок RPC, яка під час передавання захищається такою транспортною безпекою (припущення T5 і підрозділ 6.7). Доки квитанції не міститимуть офлайн-доказів остаточності, верифікатору, якому потрібна постквантова гарантія для цих перевірок, слід отримувати дані ланцюга через канал, якому він довіряє, або від кількох незалежно експлуатованих кінцевих точок.

© 2026 Quantova Inc. Qstamp і Quantova є торговельними марками Quantova Inc.

14. Список літератури

1. [1]P. W. Shor. Algorithms for quantum computation: discrete logarithms and factoring. In Proceedings of the 35th Annual Symposium on Foundations of Computer Science (FOCS), IEEE, 1994, pp. 124 to 134.
2. [2]P. W. Shor. Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer. SIAM Journal on Computing 26(5), 1997, pp. 1484 to 1509.
3. [3]L. K. Grover. A fast quantum mechanical algorithm for database search. In Proceedings of the 28th Annual ACM Symposium on Theory of Computing (STOC), 1996, pp. 212 to 219.
4. [4]C. H. Bennett, E. Bernstein, G. Brassard and U. Vazirani. Strengths and weaknesses of quantum computing. SIAM Journal on Computing 26(5), 1997, pp. 1510 to 1523.
5. [5]G. Brassard, P. Høyer and A. Tapp. Quantum cryptanalysis of hash and claw-free functions. In LATIN '98: Theoretical Informatics, Lecture Notes in Computer Science 1380, Springer, 1998, pp. 163 to 169.
6. [6]S. Aaronson and Y. Shi. Quantum lower bounds for the collision and the element distinctness problems. Journal of the ACM 51(4), 2004, pp. 595 to 605.
7. [7]D. J. Bernstein. Cost analysis of hash collisions. Will quantum computers make SHARCS obsolete? In Workshop Record of SHARCS 2009, Special-purpose Hardware for Attacking Cryptographic Systems, 2009.
8. [8]M. Roetteler, M. Naehrig, K. M. Svore and K. Lauter. Quantum resource estimates for computing elliptic curve discrete logarithms. In Advances in Cryptology, ASIACRYPT 2017, Lecture Notes in Computer Science 10625, Springer, 2017, pp. 241 to 270.
9. [9]J. Proos and C. Zalka. Shor's discrete logarithm quantum algorithm for elliptic curves. Quantum Information and Computation 3(4), 2003, pp. 317 to 344.
10. [10]C. Gidney and M. Ekerå. How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits. Quantum 5, 433, 2021. First circulated as arXiv:1905.09749, 2019.
11. [11]C. Gidney. How to factor 2048 bit RSA integers with less than a million noisy qubits. arXiv:2505.15917, 2025.
12. [12]M. A. Nielsen and I. L. Chuang. Quantum Computation and Quantum Information. Cambridge University Press, 2000.
13. [13]M. Mosca. Cybersecurity in an era with quantum computers. Will we be ready? IEEE Security and Privacy 16(5), 2018, pp. 38 to 41.
14. [14]S. Goldwasser, S. Micali and R. L. Rivest. A digital signature scheme secure against adaptive chosen-message attacks. SIAM Journal on Computing 17(2), 1988, pp. 281 to 308.
15. [15]M. Bellare and P. Rogaway. Random oracles are practical. A paradigm for designing efficient protocols. In Proceedings of the 1st ACM Conference on Computer and Communications Security (CCS), 1993, pp. 62 to 73.
16. [16]D. Boneh, Ö. Dagdelen, M. Fischlin, A. Lehmann, C. Schaffner and M. Zhandry. Random oracles in a quantum world. In Advances in Cryptology, ASIACRYPT 2011, Lecture Notes in Computer Science 7073, Springer, 2011, pp. 41 to 69.
17. [17]P. Rogaway and T. Shrimpton. Cryptographic hash-function basics. Definitions, implications, and separations for preimage resistance, second-preimage resistance, and collision resistance. In Fast Software Encryption, FSE 2004, Lecture Notes in Computer Science 3017, Springer, 2004, pp. 371 to 388.
18. [18]R. C. Merkle. A digital signature based on a conventional encryption function. In Advances in Cryptology, CRYPTO '87, Lecture Notes in Computer Science 293, Springer, 1988, pp. 369 to 378.
19. [19]S. Haber and W. S. Stornetta. How to time-stamp a digital document. Journal of Cryptology 3(2), 1991, pp. 99 to 111.
20. [20]L. Ducas, E. Kiltz, T. Lepoint, V. Lyubashevsky, P. Schwabe, G. Seiler and D. Stehlé. CRYSTALS-Dilithium. A lattice-based digital signature scheme. IACR Transactions on Cryptographic Hardware and Embedded Systems 2018(1), pp. 238 to 268.
21. [21]E. Kiltz, V. Lyubashevsky and C. Schaffner. A concrete treatment of Fiat-Shamir signatures in the quantum random-oracle model. In Advances in Cryptology, EUROCRYPT 2018, Lecture Notes in Computer Science 10822, Springer, 2018.
22. [22]National Institute of Standards and Technology. SHA-3 Standard. Permutation-Based Hash and Extendable-Output Functions. FIPS PUB 202, August 2015.
23. [23]National Institute of Standards and Technology. Secure Hash Standard (SHS). FIPS PUB 180-4, August 2015.
24. [24]National Institute of Standards and Technology. Module-Lattice-Based Digital Signature Standard. FIPS 204, August 2024.
25. [25]National Institute of Standards and Technology. Stateless Hash-Based Digital Signature Standard. FIPS 205, August 2024.
26. [26]National Institute of Standards and Technology. Digital Signature Standard (DSS). FIPS 186-5, February 2023.
27. [27]D. Moody, R. Perlner, A. Regenscheid, A. Robinson and D. Cooper. Transition to Post-Quantum Cryptography Standards. NIST Internal Report 8547, Initial Public Draft, National Institute of Standards and Technology, November 2024.
28. [28]Executive Order 14412. Securing the Nation Against Advanced Cryptographic Attacks. The White House, Washington, signed 22 June 2026.
29. [29]Certicom Research. SEC 2. Recommended Elliptic Curve Domain Parameters. Standards for Efficient Cryptography, Version 2.0, 2010.
30. [30]S. Josefsson and I. Liusvaara. Edwards-Curve Digital Signature Algorithm (EdDSA). RFC 8032, Internet Engineering Task Force, January 2017.
31. [31]B. Laurie, E. Messeri and R. Stradling. Certificate Transparency Version 2.0. RFC 9162, Internet Engineering Task Force, December 2021.
32. [32]A. Rundgren, B. Jordan and S. Erdtman. JSON Canonicalization Scheme (JCS). RFC 8785, Internet Engineering Task Force, June 2020.
33. [33]C. Adams, P. Cain, D. Pinkas and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). RFC 3161, Internet Engineering Task Force, August 2001.
34. [34]T. Gondrom, R. Brandner and U. Pordesch. Evidence Record Syntax (ERS). RFC 4998, Internet Engineering Task Force, August 2007.
35. [35]Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, L series, 12 July 2024.
36. [36]Regulation (EU) 2024/1183 of the European Parliament and of the Council of 11 April 2024 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework. Official Journal of the European Union, L series, 30 April 2024.
37. [37]United States Securities and Exchange Commission. Rule 17a-4, Records to be preserved by certain exchange members, brokers and dealers. 17 CFR 240.17a-4.
38. [38]Regulation (EU) 2016/679 as it forms part of the law of the United Kingdom (UK GDPR), Article 5(1)(f).
39. [39]Japan. Act on Special Provisions concerning Preservation Methods for Books and Documents Related to National Tax Prepared by Means of Computers (Act No. 25 of 1998), and its Enforcement Regulation.
40. [40]Republic of Korea. Personal Information Protection Act, Article 29, and the standards on safety measures for personal information issued under it by the Personal Information Protection Commission.
41. [41]Hong Kong Special Administrative Region. Personal Data (Privacy) Ordinance (Cap. 486), Schedule 1, Data Protection Principle 4.