QuantovaQstampby Quantova
FIL
EnglishEN日本語JAFilipinoFIL한국어KO简体中文ZHFrançaisFREspañolESУкраїнськаUK
GitHub Simulan ang pagbuo →
Qstamp / Daloy ng datos
Daloy ng datos

Ano ang gumagalaw saan, at ano ang hindi kailanman umaalis sa inyong mga sistema.

Sinusunod ng bawat produkto sa pamilyang Qstamp ang parehong tatlong daloy. Sineselyuhan ang isang rekord sa loob ng mga sistema ng may-ari nito, ina-anchor ang isang salted commitment sa Quantova network, at maaaring beripikahin kalaunan ng anumang partido ang rekord laban sa resibo nito. Sinusubaybayan ng pahinang ito ang bawat daloy nang hakbang-hakbang at eksaktong isinasaad kung aling datos ang tumatawid sa aling hangganan.

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
Mga hangganan

Tatlong zone, at ang datos na pinahihintulutan sa bawat isa.

Ang tuntunin sa disenyo ng pamilya ay hindi kailanman umaalis ang nilalaman ng rekord sa zone ng may-ari nito. Mga commitment na may fixed length lamang ang tumatawid sa network, at mga chain fact lamang ang pampubliko.

Zone 1

Sa loob ng inyong mga sistema

  • Ang rekord at ang mga dokumento nito
  • Mga signing key at salt
  • Personal at komersyal na datos
  • Mga nilagdaang envelope at resibo
Zone 2

Ipinadala sa network

  • Isang salted na 32 byte na commitment kada batch
  • Ang uri ng rekord, gaya ng QTax
  • Isang transaksyong nilagdaan gamit ang ML DSA 65
  • Walang maibabalik tungo sa nilalaman
Zone 3

Pampubliko sa QVMScan

  • Ang commitment at ang address ng signer
  • Ang block, ang oras nito at ang finality nito
  • Ang uri ng rekord at ang laki ng batch
  • Walang rekord, dokumento o pagkakakilanlan
Daloy 1

Pagseselyo ng isang rekord, sa loob ng inyong mga sistema.

Nangyayari ang pagseselyo kung saan nalikha ang rekord, nang hindi kinakailangan ng access sa network.

  1. 01Pagkuha

    Lumilikha ang application ng rekord sa sandaling mangyari ang pangyayari, gaya ng isang aksyon ng agent, isang filing o isang pagbabayad.

  2. 02Canonical encoding

    Ina-encode ang rekord sa isang fixed na binary form, kaya ang parehong rekord ay laging gumagawa ng parehong byte at walang field na maibibigay-kahulugan muli.

  3. 03Lagda

    Nilalagdaan ang rekord gamit ang ML DSA sa ilalim ng isang context string na natatangi sa produkto, gamit ang isang key na hawak lamang ng may-ari nito.

  4. 04Fingerprint

    Kinakalkula ang isang SHA3 256 na fingerprint sa buong na-encode na rekord at sa lagda nito, na may domain label na natatangi sa produkto.

  5. 05Salted leaf

    Isinasama ang fingerprint sa isang bagong random na salt, kaya walang anumang inilathala na magagamit upang kumpirmahin ang isang hula tungkol sa rekord.

  6. 06Batch tree

    Kinokolekta ang mga leaf sa isang Merkle tree alinsunod sa RFC 9162, kaya ang isang commitment ay maaaring sumaklaw sa libo-libong rekord.

Daloy 2

Pag-anchor ng isang commitment sa Quantova network.

Itinatakda ng pag-anchor ang commitment sa oras. Maaari itong tumakbo nang may iskedyul, sa pamamagitan ng isang controlled gateway, mula sa isang solong pinondohang account.

  1. 01Commitment

    Itinatali ang root ng batch tree sa network, sa kontrata, sa signer, sa uri ng rekord at sa laki ng batch.

  2. 02Transaksyon

    Ipinapadala ang commitment sa opisyal na kontrata ng Qstamp sa isang transaksyong nilagdaan gamit ang ML DSA 65.

  3. 03Finality

    Isang komite ng mga validator na lumalagda gamit ang ML DSA 65 ang nagpapapinal sa block, karaniwan sa loob ng humigit-kumulang 0.2 segundo.

  4. 04Event

    Nagbubuga ang kontrata ng isang event na may dalang signer, commitment at uri ng rekord, na nakikita sa QVMScan.

  5. 05Resibo

    Ang bawat rekord ay tumatanggap ng sarili nitong resibo na may inclusion path nito, salt nito at ang transaksyon, na iniimbak kasama ng rekord.

  6. 06Recovery

    Kung mabigo ang koneksyon pagkatapos ipadala, pinananatili ang isang pending stamp at nakukumpleto ang anchor sa kalaunan, kaya walang rekord na na-anchor nang dalawang ulit.

Daloy 3

Pagberipika ng isang rekord, ng kaninuman, anumang oras.

Kinakailangan ng beripikasyon ang rekord, ang envelope nito, ang resibo nito at ang public key ng signer. Hindi nito kinakailangan ang software ng Quantova o ang mga sistema ng producer.

  1. 01Lagda

    Sinusuri ng verifier ang lagdang ML DSA laban sa public key na nakasaad sa rekord at laban sa mga pinagkakatiwalaang key na inaasahan nito.

  2. 02Mga link

    Kung umaasa ang rekord sa mga naunang rekord, susuriin ang bawat nakaugnay na rekord upang matiyak na eksakto ito ang pinangalanan at wastong nilagdaan.

  3. 03Mga tuntunin

    Inilalapat ang mga tuntunin ng produkto, gaya ng paghihiwalay ng mga tungkulin, running total, pagkakasunod-sunod sa oras at mga limitasyon sa pagkaantala ng pag-anchor.

  4. 04Inclusion

    Kinakalkula muli ang leaf at sinusuri ang path nito tungo sa committed root.

  5. 05Chain

    Kinukumpirma ng verifier sa network na pinal na ang transaksyon at na ibinuga ng kontrata ang commitment.

  6. 06Resulta

    Ang resulta ay valid, invalid o indeterminate, na may nakalistang bawat pagsusuri. Hindi kailanman nagbubunga ng valid na resulta ang nawawalang ebidensya.

Ayon sa gamit

Ang parehong mga daloy, inilapat sa mga totoong rekord.

GamitRekord na sineselyuhanNakaugnay saAno ang mapapatunayan ng verifier
Mga AI agentBawat tool call, pagbabago sa modelo at desisyonAng naunang log entry at ang mandato ng agentKumilos ang agent sa loob ng mandato nito at walang aksyong tinanggal
Mga pagbabayad ng agentBawat payment intent at resiboAng mandato at ang mga limitasyon sa paggasta nitoNanatili ang mga pagbabayad sa loob ng mga awtorisadong limitasyon
BuwisMga filing, invoice, assessment at refundAng filing, ang assessment at ang mga naunang refundWalang refund na lumalampas sa refund na dapat bayaran at walang rekord na binackdate
ProcurementMga bid commitment, marka at awardAng abiso ng tender at ang mga nilagdaang markaWalang bid na idinagdag o pinalitan matapos ang deadline
Mga halalanMga return ng station at aksyon sa tabulationMga rehistradong opisyal at softwareAng ipinahayag na resulta ay katumbas ng mga sertipikadong return
Nilalamang AINilalaman, modelo at datasetMga sangkap at ang may-ari ng modeloAng pinagmulan at kasaysayan ng nilalaman ay gaya ng inaangkin
Mga key

Pag-iingat ng key sa bawat daloy.

Nililikha nang lokal

Nililikha ang mga key mula sa secure random source ng sariling sistema ng operator at hindi kailanman ipinapadala sa Quantova.

Hawak ayon sa tungkulin

Hiwalay na key ang hawak para sa hiwalay na tungkulin, kaya hindi kayang likhain at aprubahan ng isang tao o sistema ang parehong rekord.

Binubura pagkatapos gamitin

Binubura ng mga SDK ang key material mula sa memory pagkatapos ng bawat operasyon, at dapat mabasa lamang ng may-ari ang mga command line key file.