QuantovaQstampby Quantova
UK
EnglishEN日本語JAFilipinoFIL한국어KO简体中文ZHFrançaisFREspañolESУкраїнськаUK
GitHub Почати розробку →
Qstamp / Математика
Формальна конструкція

Математика, що лежить в основі кожної квитанції.

На цій сторінці точно визначено конструкцію Qstamp, зазначено рівень безпеки, якого вона досягає щодо класичних і квантових супротивників, і пояснено, чому смарт-контракти Quanta, що виконуються в Quantova Virtual Machine, придатні для закріплення цифрових відбитків дій SI-агентів.

§1 · Позначення
H(x)
SHA3 з виходом 256 біт, як визначено у FIPS 202
D
дайджест запису, обчислений за алгоритмом a, де a = 1 для SHA3 і a = 2 для SHA2 з виходом 256 біт
s
32-байтова сіль, рівномірно вибрана з генератора операційної системи
‖
конкатенація байтів
n, i
розмір пакета та позиція листа, де 1 ≤ n ≤ 2^20 і 0 ≤ i < n
G, C, S, k
хеш генезису, адреса контракту, адреса підписанта та вид запису

§2 · Лист

Li = H( 0x00 ‖ "QSTAMP/LEAF/V1" ‖ a ‖ Di ‖ si )

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

§3 · Дерево

MTH( L0 ) = L0
MTH( L0..n−1 ) = H( 0x01 ‖ MTH( L0..k−1 ) ‖ MTH( Lk..n−1 ) ), k = largest power of two below n

Це конструкція з RFC 9162, розділ 2.1. Шлях включення для листа i містить щонайбільше ⌈log2 n⌉ сусідніх хешів, тобто двадцять для найбільшого пакета. Перевірка виконується відповідно до RFC 9162, розділ 2.1.3.2, і відхиляє будь-який шлях, довжина якого не відповідає позиції та розміру.

§4 · Криптографічне зобов'язання

K = H( 0x02 ‖ "QSTAMP/ROOT/V1" ‖ G ‖ C ‖ S ‖ u64( k ) ‖ u64( n ) ‖ MTH )

Сам по собі корінь RFC 9162 не визначає розміру свого дерева, тому той самий шлях може пройти перевірку за кількох розмірів. Прив'язка n усуває цю неоднозначність. Прив'язка G, C і S означає, що криптографічне зобов'язання, скопійоване з транзакції, яка очікує на обробку, і закріплене іншим обліковим записом, контрактом або мережею, не пройде перевірку. Прив'язка k фіксує задекларований вид запису.

§5 · Закріплення в QVM

stamp( Khi , Klo , k ) → emit Stamped( caller , K , k )
caller = address( pk ) = H( scheme ‖ pk ), tx valid ⇔ ML-DSA.Verify( pk , H(body) , σ ) = 1

Контракт отримує K у вигляді двох 128-бітних слів і k у вигляді 64-бітного слова та генерує їх без змін разом з автентифікованим ініціатором виклику. До початку виконання QVM записує ініціатора виклику в пам'ять контракту з перевіреного відправника транзакції, тому на записаного підписанта неможливо вплинути через дані виклику. Подія фіксується в корені подій заголовка блоку, остаточність якого забезпечує комітет валідаторів.

§6 · Безпека

Обсяг роботи, необхідний для підроблення квитанції.

Зміна будь-якої частини закріпленої квитанції потребує знаходження другого прообразу SHA3 або зламу ML DSA. Універсальний квантовий пошук зменшує обсяг роботи з пошуку прообразу до квадратного кореня, що все одно залишає 128 біт безпеки.

АтакаНеобхідний зламКласична роботаКвантова робота
Подання іншого вмісту за наявною квитанцієюДругий прообраз SHA32^2562^128 пошуком Гровера
Зміна позиції, розміру, виду чи підписантаДругий прообраз SHA3 для криптографічного зобов'язання2^2562^128
Сторона засвідчення закріплює один дайджест для двох документівКолізія SHA32^1282^85 у моделі BHT з великою квантовою пам'яттю, близько 2^128 за реалістичних моделей вартості
Підроблення підписанта транзакції закріпленняПідроблення ML DSA 65Категорія безпеки NIST 3Категорія безпеки NIST 3
Підроблення остаточності блокуПідроблення ML DSA 65 щодо комітетуКатегорія безпеки NIST 3Категорія безпеки NIST 3
Виведення вмісту з даних ланцюгаОбернення криптографічного зобов'язання із сіллюПеребір простору солі розміром 2^2562^128
§7 · Чому контракти Quanta підходять для цифрових відбитків агентів

Властивості рівня виконання.

Автентифіковане авторство

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

Підписані доручення для делегованих повноважень

QVM перевіряє підписи ML DSA всередині контракту за допомогою інструкції VERIFY_ML у контексті QVM/contract/v1. Агенти можуть мати при собі доручення, підписані емітентом, а ретранслятор може подавати їх, не набуваючи повноважень. Кожне доручення містить nonce, що зберігається контрактом, тому його неможливо використати повторно.

Атестований код

Контракт допускається лише тоді, коли SHA3-ідентифікатор його контейнера має підпис ML DSA 65 атестованого компілятора Quanta в контексті QUANTOVA/QVM/PROVENANCE/v1. Рецензенти можуть повторно скомпілювати опублікований вихідний код і побайтно порівняти контейнер.

Передбачувана вартість

Виконання підлягає обліку ресурсів. Комісія за виклик становить 500 quon за кожні 1210 одиниць спожитих ресурсів з округленням угору, а невикористаний резерв повертається. Засвідчення коштує однаково незалежно від того, містить воно один запис чи 1048576, тому вартість однієї дії агента зменшується обернено пропорційно n.

fee( m ) = 500 · ⌈ m ⁄ 1210 ⌉ quon
cost per record = fee ⁄ n
1 TQTOV = 1,000,000 quon

§8 · Чітко сформульовані припущення

Конструкція ґрунтується на припущеннях про стійкість SHA3 і SHA2 до колізій і до пошуку другого прообразу, неможливість підроблення ML DSA 65 і чесну більшість комітету валідаторів. У випуску 0.1 транзакція закріплення, подія та блок підтверджуються через інтерфейс RPC мережі. Майбутній випуск включатиме в кожну квитанцію заголовок блоку, сертифікат остаточності та доказ включення події, що усуне залежність від будь-якої кінцевої точки. Час блоку встановлює валідатор, що пропонує блок, у цілих секундах, і він приймається лише тоді, коли відрізняється від показань годинників комітету не більше ніж на 15 секунд.