QuantovaQstampby Quantova
KO
EnglishEN日本語JAFilipinoFIL한국어KO简体中文ZHFrançaisFREspañolESУкраїнськаUK
GitHub 개발 시작하기 →
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지문

    인코딩된 기록 및 그 서명에 대하여, 제품에 고유한 도메인 라벨을 사용한 SHA3 256 지문이 계산됩니다.

  5. 05솔트 리프

    지문은 새로 생성된 무작위 솔트와 결합되므로, 공개된 어떠한 정보로도 기록에 관한 추측을 확인할 수 없습니다.

  6. 06배치 트리

    각 리프는 RFC 9162를 따르는 머클트리로 모아지므로, 하나의 커밋먼트가 수천 건의 기록을 포괄할 수 있습니다.

흐름 2

Quantova 네트워크 상에서의 커밋먼트 앵커링.

앵커링은 커밋먼트를 시각에 고정합니다. 이는 자금이 공급된 단일 계정으로부터, 통제된 게이트웨이를 통하여, 일정에 따라 실행될 수 있습니다.

  1. 01커밋먼트

    배치 트리의 루트는 네트워크, 컨트랙트, 서명자, 기록 유형 및 배치 크기에 결속됩니다.

  2. 02트랜잭션

    커밋먼트는 ML DSA 65로 서명된 트랜잭션을 통해 공식 Qstamp 컨트랙트로 전송됩니다.

  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결과

    결과는 유효, 무효 또는 판정불가 중 하나이며, 모든 확인 항목이 제시됩니다. 증거가 누락된 경우 유효하다는 결과가 산출되는 일은 결코 없습니다.

사용 사례별

동일한 흐름을, 실제 기록에 적용.

사용 사례봉인되는 기록연결 대상검증자가 증명할 수 있는 것
AI 에이전트각 도구 호출, 모델 변경 및 결정직전 로그 항목 및 에이전트 위임에이전트가 그 위임의 범위 내에서 행위하였다는 것 및 어떠한 행위도 삭제되지 않았다는 것
에이전트 결제각 결제 의사 및 영수증위임 및 그 지출 한도결제가 승인된 한도 내에 머물렀다는 것
조세신고, 송장, 과세처분 및 환급신고, 과세처분 및 이전의 환급어떠한 환급도 정당한 환급액을 초과하지 않았다는 것 및 어떠한 기록도 소급하여 날짜가 기재되지 않았다는 것
조달입찰 커밋먼트, 평가점수 및 낙찰 결정입찰공고 및 서명된 평가점수마감 이후 어떠한 입찰도 추가되거나 교체되지 않았다는 것
선거투표소 결과 보고 및 집계 행위등록된 선거관리요원 및 소프트웨어공표된 결과가 확정된 결과 보고와 일치한다는 것
AI 콘텐츠콘텐츠, 모델 및 데이터셋구성요소 및 모델 보유자콘텐츠의 출처 및 이력이 주장된 바와 같다는 것
키

모든 흐름에서의 키 보관.

로컬에서 생성

키는 운영자 자신의 시스템의 안전한 난수 소스로부터 생성되며, Quantova로 전송되는 일은 결코 없습니다.

역할별 보관

역할별로 별개의 키가 보관되므로, 한 명의 사람 또는 하나의 시스템이 동일한 기록을 생성하고 승인할 수 없습니다.

사용 후 삭제

SDK는 각 작업 이후 메모리에서 키 자료를 삭제하며, 명령줄 키 파일은 그 보유자만 읽을 수 있어야 합니다.