मुख्य कंटेंट तक स्किप करें

Protocol: Overview

यह DIG Protocol का नॉर्मेटिव स्पेसिफिकेशन है, जिसे सात layers, bottom-up के रूप में परिभाषित किया गया है। हर layer अपनी कैननिकल crate/file को नॉर्मेटिव संदर्भ के रूप में नाम देता है।

यह अथॉरिटेटिव प्रोटोकॉल संदर्भ है

यह सेक्शन इस बात का सोर्स ऑफ ट्रुथ है कि नेटवर्क क्या करता है। यह प्रोटोकॉल को वैसे ही डॉक्यूमेंट करता है जैसे यह असल में चलता है, कैननिकल इम्प्लीमेंटेशन के file:line सिटेशन्स के साथ।

मूल इकाई: capsule​

हर layer में एक ही अवधारणा चलती है: capsule = (store_id, root_hash), कैननिकल रूप से storeId:rootHash। एक store, capsules का एक क्रमबद्ध क्रम है (पुराने→नए), प्रति commit एक; इसकी पहचान store_id ही Chia पर एक CHIP-0035 DataLayer singleton launcher id है। पहचान, कंपाइलेशन, प्राइसिंग, रिट्रीवल, कैशिंग, और प्रोवेनेंस सभी प्रति capsule परिभाषित हैं।

थीसिस: ब्लाइंड host, क्लाइंट-साइड सत्यापन, चेन-एंकर्ड root​

  • ब्लाइंड host। एक host के पास केवल hashes द्वारा keyed अपारदर्शी ciphertext होता है। इसके पास कोई URN और कोई key नहीं होती, यह capsule के अपने आउटपुट को ज्यों का त्यों रिले करता है, और यह हिट को मिस से अलग नहीं बता सकता। wire पर कोई decoy फील्ड नहीं है और कोई CDN नहीं है — कंटेंट केवल dig RPC के ज़रिए सर्व किया जाता है।
  • क्लाइंट-साइड सत्यापन। हर byte को पाठक के डिवाइस पर एक ऑन-चेन root के विरुद्ध एक प्रति-resource merkle inclusion proof से जांचा जाता है, फिर authenticated-decrypt किया जाता है। भरोसा कभी सर्विंग ऑरिजिन पर टिका नहीं होता।
  • चेन-एंकर्ड root। भरोसेमंद root केवल Chia पर CHIP-0035 singleton से आता है (coinset.org के ज़रिए resolved), कभी सर्व किए गए "latest" से नहीं।

सात layers​

#Layerयह क्या परिभाषित करता हैकैननिकल संदर्भ
0Identity & namingstore, capsule, generation; store_id = launcher iddigstore-core::capsule, ::urn
0URN & addressingurn:dig:chia:… व्याकरण; rootless retrieval_keydigstore-core::urn, lib.rs
1CryptographyHKDF KDF; AES-256-GCM-SIV sealdigstore-core::crypto
1Merkle inclusion proofsD5 प्रति-resource leaf; NODE_TAG folddigstore-core::merkle
1BLS signatures & DSTsChia AugScheme; पांच role DSTsdigstore-crypto::bls
2Capsule formatDIGS डेटा सेक्शन (BINDING D1)digstore-core::datasection
2The self-defending moduleफिक्स्ड-साइज़ ऑब्फस्केशन; सर्विंग guestdigstore-compiler, digstore-guest
4On-chain anchoringstore = singleton; capsule = root-advancechip35_dl_coin, digstore-chain
4DIG CAT payment & pricingप्रति-capsule, डायनामिक, USD-peggedchip35_dl_coin::dig
6The dig RPCमशीन इंटरफेस (JSON-RPC 2.0)hub retrieval, dig-node
5§21 transport & pushdig:// locator, REST, push v1digstore-remote
7DIG Node peer networkmTLS peer identity, NAT traversal, STUN, introducer, relay wire, peer RPCdig-gossip, dig-relay, dig-nat, dig-node
7कंटेंट प्रतिकृति (फ्लाईव्हील)धारक खोजें, सत्यापित करें, कैश करें, घोषित करें — हर पठन एक नया धारक बनाता हैdig-dht, dig-download, dig-store-cache, dig-node
6Verification & provenanceचार क्रमबद्ध integrity gatesdigstore-core::merkle, dig-node
6The blind host modelprovider-blindness; resolver; /v1 कंट्रोल प्लेनhub retrieval/resolver/api
—Conformance & parityक्रॉस-implementation parity अनुशासनfrozen goldens, OpenRPC diff

(Layers 3 और §21 transport read path के साथ इंटरलीव होते हैं — तालिका उन्हें वहां ग्रुप करती है जहां एक पाठक उनसे मिलता है। पूरी layer नंबरिंग हर पेज पर दी गई है।)

एक capsule layers से कैसे गुज़रता है​

एक पब्लिशर कंटेंट को chunk + encrypt (L1) करके एक capsule format (L2) में डालता है जो self-serve (L3) करता है, इसे ऑन-चेन एंकर (L4) करता है, और इसे §21 transport (L5) पर push करता है। कोई भी क्लाइंट इसे dig RPC के ज़रिए पढ़ता है और इसे पूरी तरह क्लाइंट-साइड पर चेन-एंकर्ड root के विरुद्ध सत्यापित (L6) करता है। हर क्रिप्टोग्राफिक constant की producer, host, और verifier में साझा एक परिभाषा होती है — C8 parity invariant।

शब्दावली​

  • chia:// — नेटवर्क कंटेंट एड्रेस (जो एक ब्राउज़र खोलता है)।
  • dig:// — §21 transport locator (CLI/peer प्लेन) और DIG Browser की इंटरनल पेज स्कीम — दो अलग उपयोग, कभी कंटेंट एड्रेस नहीं।
  • urn:dig: — URN नेमस्पेस जिससे दोनों derive होते हैं।
  • store / capsule — पहचान और उसका अपरिवर्तनीय generation।
  • $DIG — प्रति capsule भुगतान किया गया CAT; dig-store — store फॉर्मेट।