GIWA 무결성 검증
실사한 저장소에서 GIWA contract, schema UID, 대표 transaction, Explorer 링크를 찾지 못했다.
contract, transaction, Explorer 검증이 생기기 전까지는 개발 계획으로만 다룬다.
해결하려는 문제
리포트를 흔적 없이 고칠 수 있으면 외부 검토자가 현재본을 판단하기 어렵다. 파일 hash는 두 파일이 같은지만 확인한다. 어느 revision이 현재본인지, 왜 바뀌었는지, 폐기된 버전인지까지는 알려주지 않는다.
목표 설계
GIWA에는 발행된 revision에 대한 비식별 commitment와 그 상태 전이만 기록하는 것이 목표다.
온체인 데이터에서 명시적으로 제외하는 것:
- 거래 원문
- 지갑 목록
- 금액
- 개인정보
그러면 외부 Consumer는 기반 내용에 접근하지 않고도 특정 revision이 현재본인지 확인할 수 있다.
GIWA가 확인하는 것
온체인 commitment의 역할은 외부 Consumer가 특정 revision의 무결성과 현재 사용 상태를 검증하게 하는 것이다. 리포트의 세무 처리가 옳다는 것을 보증하지 않으며, 보증할 수도 없다.
무결성 검증과 세무 판단은 별개다.
기존 revision 모델과의 연결
필요한 revision 모델은 저장 계층에 이미 있다. inclusion revision, evidence bundle lineage, 정정 사유를 기록한 supersedes 관계다. 저장, revision, lineage를 참고하라.
없는 것은 체인 쪽 전부다. contract, schema, 제출 경로, 검증 client.
만들어야 하는 것
| 구성 요소 | 필요한 이유 |
|---|---|
| Contract와 schema | commitment와 상태 전이 기록 |
| Commitment 유도 | 발행된 revision에서 비식별 commitment 생성 |
| 제출 경로 | 검증된 generation과 원자적으로 commitment 발행 |
| 검증 client | 외부 Consumer가 current revision 상태를 확인 |
| Explorer 증거 | 검토자가 확인할 수 있는 대표 transaction |
challenge 메커니즘은 이후 로드맵 항목으로 논의됐다. V1의 일부로 주장하지 않는다.
주장하기 전에 필요한 증빙
- 배포된 contract와 schema UID
- Explorer 링크가 있는 대표 transaction
- 정상 리포트의 검증 성공
- 변조된 리포트의 검증 실패
- 폐기된 revision의 검증 거부
- 개인정보와 온체인 payload 경계 확인