좁은 허리는 작은 원시 요소 집합이며, 각각이 엄격하게 규정되어 있습니다(RFC 2119 — MUST / MUST NOT / SHOULD). 그래서 그 위의 모든 것이 완전한 자유로 꽂힙니다. 아래 표는 각 원시 요소의 모듈과 불변식을 보여 줍니다. 성숙도 열은 설계 수준의 요약이며 — 정확한 현재 구현 상태는 현황과 라이브 네트워크 에 있습니다.

#	원시 요소	모듈	핵심 불변식	성숙도
1	UIR — Universal Identity Root	`x/uir`	하나의 글로벌 신원. 체인별 계정은 결정적으로 유도. 서명 하나로 인가	실제
2	UAC — Universal Asset Commitment	`x/uac`	총량 불변식 `total == Σ perChain + lockedInTransit`. 자산별 최소 보안 등급. 2 도메인 경계를 강제	실제
3	XMP — XChain Messaging Protocol	`x/xmp`	신뢰를 최소화한 메시징. READ와 WRITE의 깔끔한 분리	실제(재전송 방지 + 봉쇄)
4	PAI — Proof Aggregation Interface	`x/pai`	부모가 자식을 다시 실행하지 않고 검증. 재귀적 집계	집계는 실제 · prover: 현황 참조
5	DA Interface(계층형)	`fabric/da` + `tools/dasidecar`	커밋된 데이터는 해당 tier의 정책에 따라 가져올 수 있고 표본을 뽑을 수 있음	실제(Celestia)
6	VLC — Verifiable Log Commitment	`x/vlc`	추가 전용 로그: 위변조 감지 + 타임스탬프 + 포함 증명 가능. 가치를 담지 않음	실제(RFC 6962 Merkle)
7	SC — Settlement Contract	`x/settlement`	최소한의 Settlement Layer 로직: 지역 간 가치를 확정하고 집계된 증명을 소비	실제(블라인드 커밋먼트 없음)

⚠️ 증명 시스템은 의도적으로 분리 가능하게 만들었습니다. PAI의 집계(STC → Cell → Root)는 실제이지만, 암호학적 prover는 교체 가능한 부품입니다. 설계상 ProofSystem.MOCK은 테스트넷이 아닌 모든 네트워크에서 거부됩니다. 돌아가는 네트워크가 지금 MOCK을 쓰는지 진짜 prover를 쓰는지는 현황의 문제이며, 현황과 라이브 네트워크 가 답합니다 — 그래서 prover가 앞으로 나아가도 이 설계 문서는 낡지 않습니다.

원시 요소들은 엄격한 의존 순서로 조합됩니다: UIR → (UAC, XMP); DA → (VLC, PAI); (UAC, XMP, PAI, VLC) → SC.

다이어그램

그림 6 — 일곱 가지 원시 요소의 의존 그래프.

요점: 작고 올바른 핵심을 얼려 두면 수천 명이 그 위에 전혀 다른 것들을 만들면서도 서로 맞물릴 수 있습니다. 인터넷은 TCP/IP로 그것을 해냈습니다. XChain은 검증 가능한 데이터에 대해 같은 일을 합니다. 핵심이 정해졌으니 공정한 질문은, 이 설계가 빌려온 시스템들 사이에서 어디에 서 있는가입니다 — 다음 절이 순위를 매기기 전에 축부터 정의하고 묻고 답합니다.