Qstamp / Потоки даних
Потоки даних

Що куди рухається і що ніколи не виходить за межі ваших систем.

Кожен продукт у сімействі Qstamp виконує одні й ті самі три потоки. Запис запечатується в системах його власника, криптографічне зобов'язання із сіллю закріплюється в мережі Quantova, і будь-яка сторона може пізніше перевірити запис за його квитанцією. Ця сторінка покроково простежує кожен потік і точно визначає, які дані перетинають яку межу.

Live flow

The three flows in motion.

Each step lights in turn as a record moves through it. Steps inside your systems never send content out. Only the anchor reaches the Quantova network, and only chain facts are public on QVMScan.

Live flowQstamp, from your application to the explorer
  1. Your systemsYour applicationCreates a record, a decision, a model or a document
  2. Your systemsQstamp SDKSHA3 256 fingerprint bound to a fresh random salt
  3. Your systemsBatch treeUp to 1,048,576 records in one RFC 9162 tree
  4. Quantova networkQstamp contractCommitment anchored in a transaction signed with ML DSA 65
  5. Quantova networkFinalityValidator committee finalises the block in about 0.2 seconds
  6. PublicQVMScanAnchor public, record content private
  7. PublicAny verifierProves the record existed unchanged at that time
Inside your systemsQuantova networkPublic and verifiable
Межі

Три зони і дані, дозволені в кожній.

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

Зона 1

У ваших системах

  • Запис і його документи
  • Ключі підпису та сіль
  • Персональні та комерційні дані
  • Підписані конверти та квитанції
Зона 2

Надіслано до мережі

  • Одне 32-байтове криптографічне зобов'язання із сіллю на кожен пакет
  • Вид запису, наприклад QTax
  • Транзакція, підписана за допомогою ML DSA 65
  • Нічого, що можна перетворити назад на зміст
Зона 3

Публічно на QVMScan

  • Криптографічне зобов'язання та адреса підписанта
  • Блок, його час і його остаточність
  • Вид запису і розмір пакета
  • Жодного запису, документа чи ідентичності
Потік 1

Запечатування запису у ваших системах.

Запечатування відбувається там, де створюється запис, без потреби в доступі до мережі.

  1. 01Фіксація

    Застосунок створює запис у момент виникнення події, наприклад дії агента, подання декларації або платежу.

  2. 02Канонічне кодування

    Запис кодується у фіксованій бінарній формі, тож той самий запис завжди дає ті самі байти і жодне поле не можна переінтерпретувати.

  3. 03Підпис

    Запис підписується за допомогою ML DSA в межах контекстного рядка, унікального для продукту, з використанням ключа, яким володіє лише його власник.

  4. 04Відбиток

    256-бітовий цифровий відбиток SHA3 обчислюється для закодованого запису та його підпису з доменною міткою, унікальною для продукту.

  5. 05Лист із сіллю

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

  6. 06Дерево пакета

    Листки збираються у дерево Merkle відповідно до RFC 9162, тож одне криптографічне зобов'язання може охоплювати тисячі записів.

Потік 2

Закріплення криптографічного зобов'язання в мережі Quantova.

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

  1. 01Зобов'язання

    Корінь дерева пакета пов'язується з мережею, контрактом, підписантом, видом запису та розміром пакета.

  2. 02Транзакція

    Криптографічне зобов'язання надсилається до офіційного контракту Qstamp у транзакції, підписаній за допомогою ML DSA 65.

  3. 03Остаточність

    Комітет валідаторів, що підписують за допомогою ML DSA 65, робить блок остаточним, зазвичай протягом приблизно 0,2 секунди.

  4. 04Подія

    Контракт генерує подію, що містить підписанта, криптографічне зобов'язання та вид запису, видиму в QVMScan.

  5. 05Квитанція

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

  6. 06Відновлення

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

Потік 3

Перевірка запису будь-ким у будь-який час.

Для перевірки потрібні запис, його конверт, його квитанція та публічний ключ підписанта. Вона не потребує програмного забезпечення Quantova чи систем виробника запису.

  1. 01Підпис

    Верифікатор перевіряє підпис ML DSA за публічним ключем, зазначеним у записі, і за довіреними ключами, яких він очікує.

  2. 02Зв'язки

    Якщо запис залежить від попередніх записів, кожен пов'язаний запис перевіряється на те, що це саме той запис, який названо, і що він дійсно підписаний.

  3. 03Правила

    Застосовуються правила продукту, такі як розподіл обов'язків, накопичувальні підсумки, впорядкування в часі та обмеження на затримку закріплення.

  4. 04Включення

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

  5. 05Ланцюг

    Верифікатор підтверджує в мережі, що транзакція є остаточною і що контракт згенерував криптографічне зобов'язання.

  6. 06Результат

    Результатом є дійсний, недійсний або невизначений результат, з переліком усіх перевірок. Відсутність доказів ніколи не дає дійсного результату.

За сценарієм використання

Ті самі потоки, застосовані до реальних записів.

Сценарій використанняЗапечатаний записПов'язано зЩо може довести верифікатор
ШІ-агентиКожен виклик інструменту, зміна моделі та рішенняПопередній запис журналу та доручення агентаАгент діяв у межах свого доручення, і жодну дію не було видалено
Платежі агентівКожен платіжний намір і квитанціяДоручення та його ліміти витратПлатежі залишалися в межах дозволених лімітів
ОподаткуванняДекларації, рахунки, нарахування та відшкодуванняДекларація, нарахування та попередні відшкодуванняЖодне відшкодування не перевищує належного відшкодування, і жодний запис не було датовано заднім числом
Публічні закупівліТендерні зобов'язання, оцінки та рішення про переможцяТендерне повідомлення та підписані оцінкиЖодної тендерної пропозиції не додано і не замінено після кінцевого строку
ВибориПротоколи дільниць і дії з підрахункуЗареєстровані посадові особи та програмне забезпеченняОголошений результат відповідає засвідченим протоколам
Контент ШІКонтент, моделі та набори данихСкладники та власник моделіПоходження та історія контенту відповідають заявленим
Ключі

Зберігання ключів у кожному потоці.

Генерується локально

Ключі генеруються з безпечного джерела випадковості власної системи оператора і ніколи не передаються Quantova.

Розподілено за ролями

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

Видаляється після використання

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