qub प्रोटोकॉल विनिर्देश

qub क्रिप्टोग्राफिक कालिक प्रतिबद्धताओं के लिए एक प्रोटोकॉल है: शब्दों को भविष्य की तारीख तक मुहरबंद करने और बाद में ठीक-ठीक सत्यापित करने की प्रणाली कि क्या मुहरबंद था, किस drand राउंड ने उसके रिलीज़ को रोका और—संग्रहण लेन-देन या पारदर्शिता-लॉग प्रमाण उपलब्ध होने पर—ciphertext कब तक प्रतिबद्ध हो चुका था इसकी स्वतंत्र रूप से समय-मुद्रित ऊपरी सीमा।

तीन आदिम तत्व इसे कार्यान्वित करते हैं। drand एक विकेन्द्रीकृत यादृच्छिकता बीकन है—प्रकटीकरण की तारीख qub की सद्भावना के बजाय क्रिप्टोग्राफिक रूप से लागू होती है। टिकाऊ संग्रहण और append-only पारदर्शिता लॉग मुहरबंद बाइट्स को बनाए रखते हैं तथा batch की गई प्रतिबद्धताओं को स्थायी सार्वजनिक संग्रहण पर एंकर करते हैं; सशुल्क T3 पथ एक अलग स्थायी-संग्रहण लेन-देन भी लिखता है। ML-DSA-65 एक उत्तर-क्वांटम डिजिटल हस्ताक्षर है—लेखकत्व सक्षम होने पर qub ऐसे कुंजी जोड़े से बँधा है जिसकी गुप्त कुंजी लेखक के डिवाइस को कभी नहीं छोड़ती।

मिलकर ये आदिम तत्व ऐसा कथन बनाते हैं जो समय-बद्ध और छेड़छाड़-स्पष्ट, वैकल्पिक रूप से श्रेय-योग्य तथा स्वतंत्र रूप से समय-मुद्रित करने योग्य है—एक रसीद जिसका मूल्य दुनिया की अतीत गढ़ने की क्षमता बढ़ने के साथ बढ़ता है।

इस दस्तावेज़ का शेष भाग अंतर-संचालनीय कार्यान्वयनों के लिए आवश्यक मानक विनिर्देशन है।

qub प्रोटोकॉल विनिर्देशन

यह दस्तावेज़ qub समयबद्ध प्रतिबद्धता प्रणाली के लिए मानक प्रोटोकॉल विनिर्देशन है। यह डेटा संरचनाओं, क्रमबद्धता नियमों, व्युत्पत्ति सूत्रों और सत्यापन प्रक्रियाओं को परिभाषित करता है जो अंतर-संचालनीय कार्यान्वयनों के लिए आवश्यक हैं।

कार्यक्षेत्र: प्रोटोकॉल परत जानबूझकर भाषा-तटस्थ है — qub का बॉडी अपारदर्शी प्लेनटेक्स्ट / मार्कडाउन / संधि बाइट्स है, और लोकेल-संवेदी रेंडरिंग दर्शक की जिम्मेदारी है (qub.social वेब ऐप, <qub-embed> iframe, MCP क्लाइंट, इत्यादि)।

1. संकेतन और परिपाटियाँ

प्रीइमेज निर्माणों में सभी पूर्णांक big-endian स्थिर-चौड़ाई बाइट सरणियों के रूप में एन्कोड किए जाते हैं (i64 → 8 बाइट्स, u8 → 1 बाइट), जब तक अन्यथा निर्दिष्ट न हो।

सभी टाइमस्टैम्प UTC में Unix सेकंड हैं।

2. डेटा संरचनाएँ

2.1 ComposeQub (रचयिता की इन-मेमोरी स्थिति)

CBOR में क्रमबद्ध नहीं। स्थायी संग्रहण में नहीं लिखा गया। रचयिता ऐप के लिए स्थानीय।

ComposeQub {
    draft_id:       [u8; 16],        // Random, generated locally
    created_at:     i64,             // Unix seconds UTC
    unlock_at:      Option<i64>,     // Unix seconds UTC; None while composing
    visibility:     u8,              // 0x00 = private; 0x01 = public
    content_type:   u8,              // 0x01 text; 0x03 pact; 0x04 verdict
    plaintext:      Vec<u8>,         // Raw body bytes (UTF-8 for text)
    sender_label:   Option<String>,  // Display name; V2-signed when authorship is enabled
    title:          Option<String>,  // Plaintext countdown title; bound via title_hash
    reply_to:       Option<[u8; 32]>,// Parent qub_id; V2-signed when authorship is enabled
    outcome_at:     Option<i64>,     // Optional future judgment time; bound to qub_id
    status:         DraftStatus,     // Composing | Sealed | Uploaded | Failed
}

2.2 QubEnvelope (डिक्रिप्ट किया गया पेलोड)

कैनोनिकल CBOR (§3) का उपयोग करके क्रमबद्ध। SealedQub के अंदर एन्क्रिप्ट किया गया। यह वह संरचना है जो डिक्रिप्शन के बाद सामग्री अखंडता को प्रमाणित करती है।

QubEnvelope {
    version:             u8,              // Protocol major version (0x01 for v1)
    qub_id:              [u8; 32],        // Derived (see §4.1)
    content_type:        u8,              // Content type registry (see §6)
    created_at:          i64,             // Unix seconds UTC
    unlock_at:           i64,             // Unix seconds UTC
    outcome_at:          Option<i64>,     // When reality renders judgment; bound to qub_id
    sender_label:        Option<String>,  // Not in qub_id; V2-signed when authorship is enabled
    reply_to:            Option<[u8; 32]>,// Parent qub_id; not in qub_id; V2-signed when present
    body:                Vec<u8>,         // UTF-8 text or canonical CBOR pact/verdict body
    body_hash:           [u8; 32],        // SHA3-256(body) (see §4.2)
    sig_alg:             u8,              // Signature algorithm (see §9.2)
    author_signature:    Option<Vec<u8>>, // Set when sig_alg != 0x00
    author_pubkey:       Option<Vec<u8>>, // Set when sig_alg != 0x00
    cosigner_pubkey:     Option<Vec<u8>>, // Set for cosigned pact bilateral agreements
    cosigner_signature:  Option<Vec<u8>>, // Set for cosigned pact bilateral agreements
}

आधार रेखा (अहस्ताक्षरित टेक्स्ट qub): version = 0x01, content_type = 0x01, sig_alg = 0x00; हस्ताक्षर और सह-हस्ताक्षरकर्ता फ़ील्ड अनुपस्थित हैं। अन्य वैकल्पिक मेटाडेटा फ़ील्ड मौजूद हो सकते हैं।

अन्य v1 कॉन्फ़िगरेशन: content_type = 0x03 (संधि बॉडी, देखें §6.1); sig_alg = 0x01 (ML-DSA-65) author_signature और author_pubkey मौजूद के साथ (देखें §9.3); सह-हस्ताक्षरित संधियों के लिए cosigner_pubkey और cosigner_signature एक साथ उपस्थित (देखें §9.7); उत्तर-शृंखला qubs के लिए reply_to मूल qub के qub_id पर सेट (हस्ताक्षर दायरे के निहितार्थ के लिए §9.3 देखें)।

2.3 SealedQub (कैनोनिकल वायर प्रारूप)

कैनोनिकल CBOR (§3) का उपयोग करके क्रमबद्ध। यह आंतरिक वायर कलाकृति है: सार्वजनिक डिलीवरी इन बाइट्स को बिना रैप किए संग्रहीत करती है, जबकि निजी डिलीवरी संग्रहण से पहले इन्हें OuterWrapper में रैप करती है (§13)।

SealedQub {
    version:           u8,              // Protocol major version (0x01 for v1)
    qub_id:            [u8; 32],        // Same as QubEnvelope.qub_id
    visibility:        u8,              // 0x00 = private/wrapped; 0x01 = public/bare
    unlock_at:         i64,             // Unix seconds UTC
    outcome_at:        Option<i64>,     // Surfaced on the verdict-watch CTA
                                        //   before reveal; mirrors QubEnvelope.outcome_at;
                                        //   bound to qub_id via the §4.1 preimage.
    drand_chain_id:    String,          // drand chain hash (hex string)
    drand_round:       u64,             // Target drand round number
    drand_chain_version: Option<u8>,    // W3 — chain-migration version. Absent / 0 = quicknet
                                        //   (the only chain today). Lets a future chain swap
                                        //   be expressed on the wire without a breaking format
                                        //   change. NOT part of the §4.1 qub_id preimage, so its
                                        //   addition never alters an existing qub's identity.
    tlock_ciphertext:  Vec<u8>,         // tlock-encrypted QubEnvelope CBOR bytes
    recipient_pubkey:  Option<[u8; 32]>,// Reserved field; accepted by canonical CBOR
                                        //   but not interpreted by the v1 reference viewer
    title:             Option<String>,  // Plaintext title surfaced on the viewer
                                        //   countdown before reveal. Bound to qub_id
                                        //   via title_hash (§4.1). 1..=100 NFC code
                                        //   points, no hostile/control code points.
}

2.4 RevealedQub (दर्शक एप्लिकेशन स्थिति)

CBOR में क्रमबद्ध नहीं। दर्शक ऐप के लिए स्थानीय। सफल डिक्रिप्शन और सत्यापन के बाद निर्मित।

RevealedQub {
    qub_id:              [u8; 32],
    arweave_tx_id:       String,
    visibility:          u8,
    content_type:        u8,
    created_at:          i64,
    unlock_at:           i64,
    outcome_at:          Option<i64>,       // Carried from both wire layers; drives the verdict-watch block
    drand_chain_id:      String,
    drand_round:         u64,
    sender_label:        Option<String>,
    title:               Option<String>,    // Carried forward from SealedQub.title
    reply_to:            Option<[u8; 32]>,
    body:                Vec<u8>,
    body_hash:           [u8; 32],
    body_hash_verified:  bool,
    author_signature:    Option<Vec<u8>>,
    author_pubkey:       Option<Vec<u8>>,
    signature_verified:  Option<bool>,
    cosigner_pubkey:     Option<Vec<u8>>,
    cosigner_signature:  Option<Vec<u8>>,
    cosigner_verified:   Option<bool>,
}

3. कैनोनिकल CBOR प्रोफ़ाइल

सभी SealedQub और QubEnvelope क्रमबद्धता इस प्रोफ़ाइल के अनुरूप होनी MUST। दिए गए समान तार्किक संरचना के साथ दो कार्यान्वयन समान बाइट्स उत्पन्न करने MUST।

3.1 एन्कोडिंग नियम

3.2 सत्यापित कैनोनिकल कुंजी क्रम

ये कुंजी क्रम मानक हैं। कार्यान्वयन ठीक इसी क्रम में कुंजियाँ उत्सर्जित करना MUST। डिबग दावे गैर-रिलीज़ बिल्ड्स में क्रमण को सत्यापित करना SHOULD।

QubEnvelope (संस्करण 0x01, अहस्ताक्षरित, सभी वैकल्पिक क्षेत्र अनुपस्थित):

"body"                (5 encoded bytes)
"qub_id"              (7 encoded bytes)
"sig_alg"             (8 encoded bytes)
"version"             (8 encoded bytes)
"reply_to"            (9 encoded bytes)   ← only if present (reply chains)
"body_hash"           (10 encoded bytes)
"unlock_at"           (10 encoded bytes)
"created_at"          (11 encoded bytes)
"outcome_at"          (11 encoded bytes)  ← only if present (verdict mechanic)
"content_type"        (13 encoded bytes)
"sender_label"        (13 encoded bytes)  ← only if present
"author_pubkey"       (14 encoded bytes)  ← only if present
"cosigner_pubkey"     (16 encoded bytes)  ← only if present (pact cosign)
"author_signature"    (17 encoded bytes)  ← only if present
"cosigner_signature"  (19 encoded bytes)  ← only if present (pact cosign)

QubEnvelope कुंजी क्रम व्युत्पत्ति: प्रत्येक कुंजी एक CBOR टेक्स्ट स्ट्रिंग है। एन्कोडेड लंबाई = 1 बाइट हेडर + स्ट्रिंग लंबाई (24 बाइट्स से कम की स्ट्रिंग के लिए)। पहले कुल एन्कोडेड लंबाई से क्रमबद्ध करें, फिर समान-लंबाई की कुंजियों के लिए शब्दकोश क्रम से।

SealedQub (संस्करण 0x01, सार्वजनिक, कोई प्राप्तकर्ता नहीं):

"title"             (6 encoded bytes)   ← only if present
"qub_id"            (7 encoded bytes)
"version"           (8 encoded bytes)
"unlock_at"         (10 encoded bytes)
"outcome_at"        (11 encoded bytes)  ← only if present (verdict mechanic)
"visibility"        (11 encoded bytes)
"drand_round"       (12 encoded bytes)
"drand_chain_id"    (15 encoded bytes)
"recipient_pubkey"  (17 encoded bytes)  ← only if present
"tlock_ciphertext"  (17 encoded bytes)
"drand_chain_version" (20 encoded bytes) ← only if present (W3; absent = quicknet)

PactTerms (संधि बॉडी, content_type 0x03):

"notes"         (6 encoded bytes)  ← only if present
"terms"         (6 encoded bytes)
"title"         (6 encoded bytes)
"party_a"       (8 encoded bytes)
"party_b"       (8 encoded bytes)
"pact_version"  (13 encoded bytes)

PactTerm (terms सरणी की पंक्ति):

"key"    (4 encoded bytes)
"value"  (6 encoded bytes)

PartyIdentifier (party_a / party_b मानचित्र):

"label"    (6 encoded bytes)
"contact"  (8 encoded bytes)  ← only if present

3.3 बाइट एन्कोडिंग संदर्भ

4. मानक व्युत्पत्तियाँ

4.1 qub_id

qub_id विशिष्ट रूप से एक qub की पहचान करता है और QubEnvelope को SealedQub से बांधता है। यह एनवेलप सामग्री से नियतात्मक रूप से व्युत्पन्न किया जाता है।

qub_id = SHA3-256(
    "QUB_ID_V2"          ||  // domain separator: ASCII bytes [0x51 0x55 0x42 0x5F 0x49 0x44 0x5F 0x56 0x32] (9 bytes) + 0x00 padding (1 byte) = 10 bytes
    version              ||  // u8 (1 byte)
    content_type         ||  // u8 (1 byte)
    created_at           ||  // i64 big-endian (8 bytes)
    unlock_at            ||  // i64 big-endian (8 bytes)
    outcome_at_or_zero   ||  // i64 big-endian (8 bytes; 0 when outcome_at is absent)
    drand_round          ||  // u64 big-endian (8 bytes)
    body_hash            ||  // [u8; 32] (32 bytes)
    title_hash               // [u8; 32] (32 bytes; absent-sentinel = [0u8; 32])
)
// Total preimage: 108 bytes → 32-byte output

डोमेन विभाजक एन्कोडिंग: स्ट्रिंग "QUB_ID_V2" 9 ASCII बाइट्स है। संरेखण के लिए 10 बाइट्स तक पहुँचने के लिए एक 0x00 पैडिंग बाइट जोड़ा जाता है। कार्यान्वयन ठीक इन 10 बाइट्स का उपयोग करना MUST: [0x51, 0x55, 0x42, 0x5F, 0x49, 0x44, 0x5F, 0x56, 0x32, 0x00]।

outcome_at एन्कोडिंग: एक pre-release कार्यान्वयन संशोधन ने वैकल्पिक outcome_at फ़ील्ड को बंधन में शामिल करने के लिए प्रीइमेज को 92 से 100 बाइट्स तक बढ़ाया। अनुपस्थित outcome_at 8 शून्य बाइट्स के रूप में एन्कोड होता है; प्रोटोकॉल सत्यापनकर्ता हर जगह outcome_at <= 0 अस्वीकार करते हैं, इसलिए यह sentinel किसी वैध मान से नहीं टकरा सकता। इस फ़ील्ड को प्रेरित करने वाले verdict mechanic के लिए §3.2 और in-tree tasks/verdict-uplift-plan.md देखें।

drand_round एन्कोडिंग: बाद के pre-release कार्यान्वयन संशोधन ने drand_round (लक्ष्य drand राउंड, §4.3) को बंधन में शामिल करने के लिए प्रीइमेज को 100 से 108 बाइट्स तक बढ़ाया और domain separator को QUB_ID_V2 किया। यह timelock राउंड को qub पहचान में बाँधता है: गेटवे ciphertext को प्रदर्शित unlock_at से निहित राउंड से भिन्न (जैसे पहले ही बीत चुके) राउंड से दोबारा नहीं बाँध सकता। अनलॉक प्रक्रिया (§8) यह भी सत्यापित करती है कि tlock ciphertext stanza का राउंड unlock_round(unlock_at) से मेल खाता है, इसलिए प्रदर्शित अनलॉक समय प्रमाणित रूप से वही राउंड है जो डिक्रिप्शन को नियंत्रित करता है।

गुण:

• प्रीइमेज से बँधे किसी भी फ़ील्ड—version, content_type, created_at, unlock_at, outcome_at, drand_round, कच्चे body बाइट्स (body_hash के माध्यम से), या title (title_hash के माध्यम से)—को बदलने पर अलग qub_id उत्पन्न होता है।
• qub_id एन्क्रिप्शन से पहले गणना की जाती है। QubEnvelope और SealedQub दोनों एक ही qub_id ले जाते हैं। दर्शक डिक्रिप्शन के बाद उनके मिलान को सत्यापित करता है।
• qub_id, sender_label, reply_to, हस्ताक्षर बाइट्स या हस्ताक्षर सार्वजनिक कुंजियों पर निर्भर नहीं करता। फिर भी वर्तमान V2 हस्ताक्षर निर्माण में हस्ताक्षर मौजूद होने पर sender_label और reply_to क्रमशः sender_label_hash और reply_to_or_zero (§9.3) द्वारा सीधे प्रमाणित होते हैं।
• SealedQub title को बदलने (बाकी सब कुछ स्थिर रखते हुए) से title_hash के माध्यम से qub_id बदलता है। इसलिए एक गेटवे qub पहचान को अमान्य किए बिना उलटी गिनती पर प्रदर्शित प्लेनटेक्स्ट शीर्षक को बदल नहीं सकता।
• SealedQub outcome_at को बदलने (बाकी सब कुछ स्थिर रखते हुए) से प्रीइमेज के माध्यम से qub_id बदलता है। एक गेटवे qub पहचान को अमान्य किए बिना उलटी गिनती पर प्रदर्शित प्रकटीकरण-पूर्व verdict-on तिथि को बदल नहीं सकता।
• drand_round को बदलने (बाकी सब कुछ स्थिर रखते हुए) से प्रीइमेज के माध्यम से qub_id बदलता है। एक गेटवे qub पहचान को अमान्य किए बिना टाइमलॉक सिफरटेक्स्ट को किसी भिन्न राउंड से दोबारा नहीं बांध सकता; §8 अनलॉक-समय स्टैन्ज़ा-राउंड जाँच के साथ मिलकर, प्रदर्शित unlock_at वही राउंड है जो वास्तव में डिक्रिप्शन को नियंत्रित करता है।

4.2 body_hash

body_hash = SHA3-256(body)

जहाँ body कच्चा Vec<u8> सामग्री पेलोड है। टेक्स्ट qubs के लिए, यह UTF-8 एन्कोडेड qub बॉडी है।

4.2.1 title_hash

title_hash = SHA3-256(NFC(title).utf8_bytes)   if title is present
title_hash = [0u8; 32]                         if title is absent

जहाँ title वैकल्पिक प्लेनटेक्स्ट शीर्षक है जो प्रकट करने से पहले दर्शक की उलटी गिनती पर सतह पर आता है (देखें §3.2)। NFC सामान्यीकरण हैश समय पर चलता है ताकि डाइजेस्ट दृश्य रूप से समकक्ष कोड-पॉइंट अनुक्रमों में स्थिर हो। सभी-शून्य सेंटीनेल अनुपस्थित मामले के लिए आरक्षित है; एक खाली स्ट्रिंग कैनोनिकल CBOR सीमा पर "अनुपस्थित" के गैर-कैनोनिकल एन्कोडिंग के रूप में अस्वीकार की जाती है (कैनोनिकल एन्कोडिंग क्षेत्र को पूरी तरह से छोड़ देता है)।

4.3 Unlock-Round मानचित्रण

drand_round = floor((unlock_at - chain_genesis_time) / chain_period_seconds) + 1

यह reference tlock mapping (drand का CurrentRound) है। drand राउंड N को chain_genesis_time + (N - 1) * chain_period_seconds पर प्रकाशित करता है, इसलिए सूत्र unlock_at पर वर्तमान राउंड चुनता है—वह राउंड जिसका हस्ताक्षर unlock_at पर आने वाला दर्शक सबसे पहले उपयोग कर सकता है।

संरेखण गुण: जब (unlock_at - chain_genesis_time) ठीक chain_period_seconds से विभाज्य होता है, चुने गए राउंड का हस्ताक्षर ठीक unlock_at पर प्रकाशित होता है, उससे पहले कभी नहीं। reference deployment में यह हमेशा लागू है: quicknet का genesis time (1692803367) उसकी 3-सेकंड अवधि से विभाज्य है और reference apps अनलॉक समय को पूरे मिनटों पर pin करते हैं। असंरेखित unlock_at के लिए हस्ताक्षर unlock_at से एक अवधि से कम पहले प्रकाशित होता है—प्रतिबद्धता की कालिक सटीकता एक beacon अवधि है।

पूर्ववर्ती pre-release mapping और unlock-side tolerance: मूल mapping ceil((unlock_at - chain_genesis_time) / chain_period_seconds) थी, जो ऊपर के period-aligned मामले में unlock_at से ठीक एक पूरी अवधि पहले प्रकाशित राउंड चुनती थी। delta अवधि से विभाज्य होने पर दोनों mappings में ठीक +1 का अंतर है और अन्यथा वे सहमत हैं। क्योंकि drand_round अपरिवर्तनीय qub_id preimage (§4.1) में शामिल है, पूर्ववर्ती mapping से मुहरबंद artifacts को दोबारा derive नहीं किया जा सकता; इसलिए §8 step 6a cross-check करने वाले verifiers को संग्रहीत drand_round को derived round या derived round minus one के बराबर स्वीकार करना MUST, और tlock stanza round को stored round के ठीक बराबर करना MUST। tolerance earliest gating signature को अधिकतम एक अवधि तक चौड़ा करता है। Pact staging service stage और co-sign के समय यही tolerance लागू करती है और finalized pact को उसी round पर मुहरबंद करती है जिससे qub_id वास्तव में बँधा है।

सत्यापन: unlock_at मुहरबंदी के समय भविष्य में होना MUST। unlock_at created_at से 10 वर्षों से अधिक नहीं होना MUST NOT (लंबे-क्षितिज drand निर्भरता जोखिम को सीमित करने के लिए; UI को 2 वर्षों से अधिक अनलॉक तिथियों के लिए चेतावनी देनी SHOULD)।

5. वायर प्रारूप न्यूटाइप्स

वायर प्रारूप न्यूटाइप्स CBOR बाइट्स को JSON, कच्चे प्लेनटेक्स्ट, या अन्य बाइट एन्कोडिंग के साथ भ्रमित होने से कंपाइल-टाइम सुरक्षा प्रदान करते हैं।

5.1 निर्माण नियम

// Production code — only through CBOR serialisers:
let sealed = SealedQubCbor::from_encoded(cbor_bytes);

// There is deliberately NO From<Vec<u8>> implementation.
// You cannot accidentally wrap arbitrary bytes in a wire format type.

// Accessing raw bytes:
let bytes: &[u8] = sealed.as_bytes();
let bytes: Vec<u8> = sealed.into_bytes();

5.2 निर्माण पर सत्यापन

from_encoded() को सत्यापित करना SHOULD कि इनपुट एक मान्य CBOR मानचित्र हेडर से शुरू होता है। पूर्ण संरचनात्मक सत्यापन पार्स समय पर होता है, निर्माण समय पर नहीं, ताकि दोहरी-पार्सिंग से बचा जा सके।

6. सामग्री प्रकार रजिस्ट्री

दर्शक अज्ञात सामग्री प्रकारों को एक स्पष्ट उपयोगकर्ता-दृश्य त्रुटि के साथ अस्वीकार करना MUST। दर्शक अज्ञात प्रकारों को टेक्स्ट के रूप में रेंडर करने का प्रयास MUST NOT।

6.1 संधि बॉडी (content_type = 0x03)

संधि बॉडी PactTerms मान का कैनोनिकल CBOR एन्कोडिंग है:

PactTerms {
    pact_version:  u8,                    // 0x01 for structured/v1
    title:         String,                // ≤ 200 bytes, NFC
    terms:         Vec<PactTerm>,         // ≤ 20 rows
    party_a:       PartyIdentifier,       // initiator
    party_b:       PartyIdentifier,       // counter-signer
    notes:         Option<String>,        // ≤ 5,000 bytes, NFC; absent key if none
}

PactTerm       { key: String (≤ 100 bytes), value: String (≤ 2,000 bytes) } // NFC
PartyIdentifier{ label: String (≤ 100 bytes), contact: Option<String (≤ 320 bytes)> }

तीनों मानचित्रों के लिए कैनोनिकल CBOR कुंजी क्रम §3.2 में दिए गए हैं। कुल क्रमबद्ध संधि CBOR 100 KB से अधिक MUST NOT (§6 से मेल खाता है)।

योजना विभेदक। structured/v1 संधि के लिए terms में पहली पंक्ति { key: "pact_schema", value: "structured/v1" } होनी MUST। इस मार्कर के बिना पंक्तियाँ "कस्टम" संधियाँ हैं और कोई संरचित सत्यापन या योजना-संवेदी रेंडरिंग प्राप्त नहीं करतीं।

स्थिर स्वीकृति स्लॉट। structured/v1 संधियाँ इन कुंजियों के अंतर्गत ठीक चार स्वीकृति पंक्तियाँ ले जाती हैं:

"initiator_standard_terms"
"initiator_capacity_terms"
"counterparty_standard_terms"
"counterparty_capacity_terms"

प्रत्येक के लिए value (role, kind) जोड़ी द्वारा चुनी गई आठ स्थिर अंग्रेज़ी स्ट्रिंग्स में से एक है, जहाँ role ∈ { seller, buyer, provider, client } और kind ∈ { standard, capacity }। स्ट्रिंग्स स्वयं मानक प्रोटोकॉल डेटा हैं — दोनों पक्षों के ML-DSA-65 हस्ताक्षर body_hash के माध्यम से सटीक बाइट्स के लिए प्रतिबद्ध होते हैं। उन्हें स्थानीयकृत नहीं किया जाता; हस्ताक्षरित बॉडी भाषा-तटस्थ है। किसी भी शब्दावली परिवर्तन के लिए एक नया योजना संस्करण (structured/v2) आवश्यक है।

आठ स्ट्रिंग्स, उनकी खोज (acknowledgement_for(role, kind)), और प्रत्येक के लिए तर्क संदर्भ कार्यान्वयन द्वारा पिन किए गए हैं। अनुरूप कार्यान्वयन बाइट-समान स्वीकृति मान उत्सर्जित करना MUST; सभी चार भूमिका संयोजनों को कवर करने वाले स्वर्ण-फ़िक्स्चर SHA3-256 बॉडी-हैश परीक्षण किसी भी विचलन को पकड़ते हैं।

दर्शक प्रदर्शन क्रम। स्वीकृति स्ट्रिंग्स में "described above" जैसे वाक्यांश होते हैं, जो मानते हैं कि विवरण / दायरा पंक्तियाँ स्वीकृतियों से पहले रेंडर होती हैं। दर्शक terms सरणी को CBOR क्रम में रेंडर करना MUST; पुनः क्रमबद्ध करने से प्रोज़ अर्थ-विज्ञान टूट जाता है।

प्रति-पक्ष संपर्क। जब पक्ष B का contact एक मान्य ईमेल पता होता है, तो qub अपलोड सेवा स्टेज समय पर एक समीक्षा / सह-हस्ताक्षर निमंत्रण ईमेल स्वतः-भेजती है और अंततः सह-हस्ताक्षर को उसी पते के सत्यापन से बांधती है (§9.7)। जिन संधियों में पक्ष B संपर्क अनुपस्थित है, उन पर अभी भी सह-हस्ताक्षर किए जा सकते हैं, लेकिन केवल बैंड-से-बाहर चैनल के माध्यम से — सेवा सह-हस्ताक्षर अनुरोधों को अस्वीकार करती है जो एक मेल खाते 15-मिनट के ईमेल-सत्यापन मार्कर का उत्पादन नहीं कर सकते।

6.2 फ़ैसला बॉडी (content_type = 0x04)

फ़ैसला बॉडी VerdictBody मान का कैनोनिकल CBOR एन्कोडिंग है:

VerdictBody {
    verdict_version: u8,                  // 0x01 for structured/v1
    outcome:         u8,                  // 1=Right · 2=Partial · 3=Wrong · 4=Unfalsifiable
    reflection:      Option<String>,      // ≤ 2,000 bytes NFC; "what changed, what did you learn"
    evidence_url:    Option<String>,      // ≤ 2,048 bytes; HTTPS only; absent key when omitted
}

कैनोनिकल CBOR कुंजी क्रम:

"outcome"          (8 encoded bytes)
"reflection"       (11 encoded bytes)  ← only if present
"evidence_url"     (13 encoded bytes)  ← only if present
"verdict_version"  (16 encoded bytes)

कुल क्रमबद्ध फ़ैसला CBOR 8 KB से अधिक MUST NOT (ऊपर दी गई रजिस्ट्री पंक्ति से मेल खाता है)।

परिणाम एनम। वायर बाइट इंटेंट-तटस्थ है; चार बकेट Right / Partial / Wrong / Unfalsifiable हर फ़ैसला-वहन करने वाले इंटेंट के परिणाम-अंतराल को कवर करते हैं। प्रति-इंटेंट लेबल (Right के लिए "सही कहा था" / "निभाया" / "जारी हुआ" / "पुष्टि हुई", आदि) एक दर्शक-पक्ष रेंडरिंग चिंता है जो मूल qub के इंटेंट के विरुद्ध हल की जाती है — वायर भाषा- और इंटेंट-तटस्थ रहती है। 1..=4 से बाहर के मान डिकोड पर अस्वीकार किए जाने MUST।

मूल संबंध। एक फ़ैसला qub अपनी बॉडी में मूल संदर्भ नहीं ले जाता। मूल qub की Arweave लेन-देन id अपलोड समय पर Parent-Tx-Id संग्रहण टैग के रूप में उत्सर्जित की जाती है (§7 संग्रहण-टैग परत)। यह बॉडी को स्व-आँकलन का एक स्व-निहित हस्ताक्षरित कथन रखता है; ऑडिट श्रृंखला ("किसके बारे में सही?") Arweave-टैग लुकअप के माध्यम से स्थापित होती है।

साक्ष्य URL सुरक्षा (मानक)। जब evidence_url उपस्थित होता है, सत्यापनकर्ता (कंपोज़-पक्ष, वायर-पक्ष, Worker एज) निम्न लागू करना MUST:

1. केवल HTTPS। स्ट्रिंग बाइट अनुक्रम https:// से शुरू होनी MUST। कोई अन्य योजना — http, ftp, javascript, data, file, आदि — अस्वीकार की जाती है।
2. लंबाई सीमा। ≤ 2,048 बाइट्स (ब्राउज़र URL व्यावहारिक सीमा)।
3. NFC + शत्रुतापूर्ण-कोडपॉइंट जाँच। title और reflection के समान नियम — bidi-override / zero-width / tag-block / BOM / C0 / C1 कोडपॉइंट अस्वीकार किए जाते हैं। परिभाषा Rust crate::handle::contains_hostile_text_codepoint और TS workers/api/src/utils/unicode.ts::isHostileCodepoint से मेल खाती है (लॉकस्टेप में रखें)।
4. कोई व्हाइटस्पेस नहीं, कोई ASCII नियंत्रण नहीं। URL में कहीं भी व्हाइटस्पेस / DEL / सब-0x20 बाइट्स अस्वीकार किए जाते हैं — \n/\t इंजेक्शन वेक्टर को बंद करता है जिसे bidi नियम कवर नहीं करता।
5. गैर-खाली होस्ट खंड। https:// और पहले /, ?, या # के बीच सब कुछ गैर-खाली होना MUST।

कोई सर्वर-पक्ष फ़ेचिंग नहीं। Worker URL को प्रॉक्सी, फ़ेच, या प्रीव्यू MUST NOT। प्रोटोकॉल एक स्ट्रिंग संग्रहित करता है; रेंडरिंग दर्शक-पक्ष पर rel="nofollow noopener noreferrer" target="_blank" और लिंक टेक्स्ट के साथ प्रदर्शित एक दृश्य होस्ट के साथ होती है।

चिंतन। वैकल्पिक रचयिता-लिखित चिंतन टेक्स्ट ("क्या बदला, आपने क्या सीखा")। title के समान NFC + शत्रुतापूर्ण-कोडपॉइंट सत्यापन। खाली / केवल-व्हाइटस्पेस इनपुट निर्माण समय पर अनुपस्थित में मुड़ जाता है।

योजना संस्करण। v1 केवल verdict_version = 0x01 का समर्थन करता है। भविष्य की योजना संशोधन इस बाइट को बढ़ाते हैं और §12 के अनुसार एक नए प्रोटोकॉल संस्करण के साथ आते हैं।

7. मुहरबंदी प्रोटोकॉल

पूर्ण मुहरबंदी अनुक्रम। प्रत्येक चरण मानक है।

 1. User composes plaintext and metadata in ComposeQub.
 2. Validate:
    a. body is non-empty.
    b. body size ≤ max for content_type and user tier (see §6).
    c. unlock_at is in the future.
    d. unlock_at ≤ created_at + 10 years.
    e. content_type is a known, supported value.
    f. visibility is 0x00 (private) or 0x01 (public).
 3. Compute body_hash = SHA3-256(body).
 4. Set created_at = current Unix seconds UTC.
 5. Select drand chain. Load chain_genesis_time and chain_period_seconds, and
    compute drand_round = floor((unlock_at - chain_genesis_time) / chain_period_seconds) + 1
    (§4.3). (Computed here, before qub_id, because drand_round is bound into the
    qub_id preimage—§4.1.)
 6. Compute qub_id (see §4.1), folding in drand_round from step 5.
 7. Construct QubEnvelope with all fields.
 8. Serialise QubEnvelope using canonical CBOR → bytes B.
    Assert: serialised output matches canonical profile (§3).
 9. Compute C = tlock_encrypt(B, drand_round, drand_chain_public_key).
10. Construct SealedQub with tlock_ciphertext = C and matching qub_id, version,
    visibility, unlock_at, drand_chain_id, and drand_round.
11. Serialise SealedQub using canonical CBOR → SealedQubCbor.
12. Select the delivery shape from visibility:
    a. Private (0x00): generate K = 32 random bytes and N = 12 random bytes
       using a CSPRNG. Compute W = wrap_sealed_qub(SealedQubCbor,
       qub_id=qub_id, key=K, nonce=N) per §13. Upload payload = W.
    b. Public (0x01): upload payload = bare SealedQubCbor; do not generate K.
13. Display seal-time disclosure. User confirms.
14. Validate upload eligibility via the qub upload service (bot-detection, entitlement, rate limits).
15. Submit the selected upload payload to the qub upload service. For a private
    browser seal, the service is byte-blind to the inner SealedQubCbor and never
    receives K. The Builder `/api/v1/seal` route is an explicit exception: it
    receives plaintext and caller-supplied K in memory, then persists neither.
16. Receive arweave_tx_id from the service. For private delivery, construct
    `<origin>/c/<arweave_tx_id>#<base64url(K)>` (or the equivalent short-code
    path). For public delivery, omit the fragment. Browsers do not transmit URL
    fragments to servers, so K from the browser-seal path is not observed by
    qub.social or any storage gateway.

संग्रहण टैग परत (बैंड-से-बाहर)। qub अपलोड सेवा चुने गए अपलोड पेलोड के साथ संग्रहण लेन-देन टैग्स का जानबूझकर छोटा सेट संलग्न करती है। Content-Type=application/octet-stream मानक रूप से आवश्यक है। संदर्भ सेवा अतिरिक्त रूप से तीन वैकल्पिक टैग संलग्न करती है जब रचयिता उन्हें सतह पर लाना चुनता है: Intent (ठीक इसी allowlist के विरुद्ध सत्यापित compose intent: announcement, thesis, prediction, letter, secret, commitment, proof, या सिस्टम द्वारा जारी verdict), Author (रचयिता की §9.3 पबकी फ़िंगरप्रिंट 64-वर्ण लोअरकेस हेक्स के रूप में), और Parent-Tx-Id (उत्तर शृंखलाओं के लिए मूल qub का संग्रहण लेन-देन ID, 43-वर्ण base64url)।

Author टैग प्रति qub ऑप्ट-इन है: संदर्भ रचयिता ऐप इसे केवल तब संलग्न करता है जब उपयोगकर्ता मुहरबंदी समय पर स्पष्ट रूप से सार्वजनिक श्रेय सक्षम करता है। जब टॉगल बंद होता है — डिफ़ॉल्ट — कोई Author टैग नहीं लिखा जाता और qub चेन पर बिना श्रेय वाला होता है: स्थायी संग्रहण में कुछ भी अपलोड को किसी रचयिता के हैंडल, ईमेल, या अन्य qubs से नहीं जोड़ता। जब टॉगल चालू होता है, Author फ़िंगरप्रिंट §9.5 अनुप्रमाणन शृंखला के माध्यम से रचयिता के चुने हुए @handle से हल हो जाता है। उत्तर-शृंखला संबंध और Intent गैर-पहचानने वाले होते हैं। निजी डिलीवरी के लिए बाहरी आवरण (§13) पहचाने जा सकने वाले आंतरिक SealedQub आर्टिफ़ैक्ट को एन्क्रिप्ट करता है, इसलिए संग्रहीत आवरणों को हार्वेस्ट करना और सार्वजनिक drand हस्ताक्षर प्राप्त करना भी K के बिना बॉडी पुनर्प्राप्त करने के लिए अपर्याप्त है; संग्रहण टैग जानबूझकर सार्वजनिक मेटाडेटा बने रहते हैं।

संदर्भ सेवा जानबूझकर App-Name, App-Version, या Type टैग संलग्न नहीं करती: किसी भी ऐसे एकल-मान फ़िल्टर से GraphQL क्वेरी को संपूर्ण qub कॉर्पस वापस मिल जाएगा, जो आवरण के बॉडी-केवल गोपनीयता दायरे के साथ असंगत है।

एक अनुरूप सत्यापनकर्ता §11 तृतीय-पक्ष सत्यापन के लिए किसी भी संग्रहण टैग पर निर्भर MUST NOT; बॉडी हैश / qub_id / हस्ताक्षर केवल आंतरिक CBOR के लिए प्रतिबद्ध होते हैं, टैग सेट के लिए कभी नहीं।

8. अनलॉक प्रोटोकॉल

पूर्ण अनलॉक अनुक्रम। प्रत्येक चरण मानक है।

 1. Viewer opens delivery URL. Extract arweave_tx_id from the path and retain
    the optional URL fragment. Do not assume a missing fragment is an error:
    public/bare delivery intentionally has no K.
 2. Check denylist. If tx_id is denylisted → display block message. Stop.
 3. Fetch the stored bytes (with multi-gateway fallback).
 3a. Resolve the delivery shape structurally:
    a. If the bytes parse as OuterWrapper, require a well-formed 32-byte K in
       the URL fragment, require wrapper version 0x01, and unwrap per §13.
       Any missing/malformed K or AEAD failure is a terminal error.
    b. Otherwise require the bytes to parse as bare SealedQubCbor; no K is
       required. If neither shape parses, report an integrity error.
 4. Parse SealedQubCbor → SealedQub.
 5. Validate: SealedQub.version is known (0x01), visibility is known, and the
    delivery shape matches it (wrapped = 0x00 private; bare = 0x01 public).
    Reject any mismatch or unknown value.
 6. If current time < SealedQub.unlock_at → display countdown. Poll or wait.
 6a. Round-binding check. Recompute expected_round from
    SealedQub.unlock_at per §4.3. Reject unless SealedQub.drand_round ==
    expected_round OR SealedQub.drand_round == expected_round - 1 (the
    legacy pre-release mapping—see §4.3), AND the round baked into the tlock
    ciphertext stanza (read via the age/tlock header, no signature required)
    == SealedQub.drand_round exactly. The stanza round is the one that
    actually gates decryption; without this check a malicious creator could
    bind the ciphertext to an already-past round while displaying a future
    countdown, so anyone reading the stored bytes could decrypt before
    unlock_at. Implementations with no chain identity (test mocks) skip this
    check.
 7. Once current time ≥ SealedQub.unlock_at:
    a. Fetch drand round signature for SealedQub.drand_round from drand network.
    b. Compute B = tlock_decrypt(SealedQub.tlock_ciphertext, round_signature).
 8. Parse B → QubEnvelope.
 9. Validate QubEnvelope.version is known.
10. Verify: SHA3-256(QubEnvelope.body) == QubEnvelope.body_hash.
    Fail → integrity error.
11. Verify: QubEnvelope.qub_id == SealedQub.qub_id.
    Fail → integrity error.
12. Verify: QubEnvelope.unlock_at == SealedQub.unlock_at.
    Fail → integrity error.
12a. Verify: QubEnvelope.outcome_at == SealedQub.outcome_at (both absent, or
    both present and equal). Fail → integrity error.
12b. Content re-derivation. Recompute qub_id per §4.1 from the decrypted
    fields — (QubEnvelope.version, content_type, created_at, unlock_at,
    outcome_at, SealedQub.drand_round, QubEnvelope.body_hash,
    title_hash(SealedQub.title)) — and verify it equals SealedQub.qub_id.
    Fail → integrity error. The pairwise checks in steps 10-12a only prove
    the two layers agree with EACH OTHER; a forger who rewrites a bound
    field consistently on both surfaces (a pre-reveal title swap, or a
    post-round body swap with a recomputed body_hash re-encrypted to the
    same round under the same qub_id) passes them all. Only re-deriving
    the identity from content closes this.
13. Verify: QubEnvelope.content_type is known and renderable.
    Known values: 0x01 (text), 0x03 (pact), 0x04 (verdict).
    Unknown → display error.
14. If QubEnvelope.sig_alg != 0x00 → verify author signature (see §9.4).
15. If cosigner_pubkey or cosigner_signature present → verify cosigner (see §9.7).
16. Render content using the appropriate renderer (see §10 for text and §6 for pact/verdict).
17. Construct RevealedQub for display.

9. लेखकत्व हस्ताक्षर

9.1 तर्क

qubs स्थायी संग्रहण में संग्रहीत किए जाते हैं। लेखकत्व हस्ताक्षरों को अनिश्चित काल तक अजेय बने रहना चाहिए, यही कारण है कि v1.0 शास्त्रीय योजना के बजाय उत्तर-क्वांटम ML-DSA-65 योजना (FIPS 204) का उपयोग करता है जिसकी सुरक्षा qub के स्थायी जीवनकाल के भीतर ख़राब हो सकती है।

9.2 एल्गोरिथम रजिस्ट्री

Protocol-v1 दर्शकों को आरक्षित 0x02 सहित {0x00, 0x01} के बाहर हर मान अस्वीकार करना MUST। आरक्षण आकस्मिक पुनः उपयोग रोकता है; यह activation नहीं है। इसे सक्रिय करने के लिए §15 में वर्णित governed change आवश्यक है।

9.3 हस्ताक्षरित प्रीइमेज निर्माण

दो प्रीइमेज संस्करण अस्तित्व में रहे हैं। सभी हस्ताक्षर V2 का उपयोग करना MUST, और सत्यापनकर्ता केवल V2 स्वीकार करना MUST। पूर्ववर्ती V1 प्रीइमेज (ऐतिहासिक संदर्भ के लिए नीचे प्रलेखित) को V2 माइग्रेशन के दौरान केवल-सत्यापन फ़ॉलबैक के रूप में स्वीकार किया जाता था; उस फ़ॉलबैक को वापस ले लिया गया है और अब केवल-V1 हस्ताक्षर अस्वीकार किया जाता है।

V2 (वर्तमान — सभी नए लेखक हस्ताक्षर द्वारा, और संधि स्टेजिंग / सह-हस्ताक्षर प्रवाह के दोनों हस्ताक्षरों द्वारा उत्पन्न):

sig_input = SHA3-256(
    "QUB_AUTHOR_SIG_V2"  ||    // domain separator (17 bytes)
    version              ||    // u8 (1 byte)
    qub_id               ||    // [u8; 32] (32 bytes)
    body_hash            ||    // [u8; 32] (32 bytes)
    unlock_at            ||    // i64 big-endian (8 bytes)
    0x00                 ||    // u8 (1 byte): MUST be 0x00 in v1.x
    sender_label_hash    ||    // [u8; 32]: SHA3-256(NFC(sender_label)),
                               //   or 32 zero bytes when absent
    reply_to_or_zero           // [u8; 32]: parent qub_id, or 32 zero
                               //   bytes when absent
)

// Total preimage: 155 bytes → 32-byte hash

signature = Sign(author_secret_key, sig_input)

sender_label_hash वही अनुपस्थित-सेंटिनल परिपाटी का पालन करता है जो title_hash (§4.2.1) करता है: 32 शून्य बाइट्स एक वैध SHA3-256 आउटपुट नहीं हैं, इसलिए "अनुपस्थित" कभी भी किसी उपस्थित लेबल से टकरा नहीं सकता। सभी क्षेत्र निश्चित-चौड़ाई के हैं, इसलिए प्रीइमेज लंबाई उपसर्गों के बिना असंदिग्ध है।

V1 (पूर्ववर्ती — वापस लिया गया; अब उत्पन्न नहीं किया जाता और सत्यापन पर अब स्वीकार नहीं किया जाता):

sig_input = SHA3-256(
    "QUB_AUTHOR_SIG_V1"  ||    // domain separator (17 bytes)
    version              ||    // u8 (1 byte)
    qub_id               ||    // [u8; 32] (32 bytes)
    body_hash            ||    // [u8; 32] (32 bytes)
    unlock_at            ||    // i64 big-endian (8 bytes)
    0x00                       // u8 (1 byte): MUST be 0x00 in v1.0
)

// Total preimage: 91 bytes → 32-byte hash

V1 प्रीइमेज ने sender_label और reply_to को छोड़ दिया था। इसे V2 में माइग्रेशन के दौरान केवल-सत्यापन फ़ॉलबैक के रूप में स्वीकार किया जाता था; तब से उस फ़ॉलबैक को वापस ले लिया गया है — सत्यापनकर्ता केवल V2 प्रीइमेज स्वीकार करना MUST। परिभाषा यहाँ ऐतिहासिक संदर्भ के लिए और नीचे दिए गए डोमेन विभाजक को समझाने के लिए बनाए रखी गई है। जो हस्ताक्षर केवल V1 के विरुद्ध सत्यापित होता है, उसे सत्यापन विफलता के रूप में माना जाना MUST।

डोमेन विभाजक: "QUB_AUTHOR_SIG_V1" / "QUB_AUTHOR_SIG_V2" प्रत्येक 17 ASCII बाइट्स हैं ([0x51, 0x55, 0x42, 0x5F, 0x41, 0x55, 0x54, 0x48, 0x4F, 0x52, 0x5F, 0x53, 0x49, 0x47, 0x5F, 0x56, 0x31/0x32])। कोई पैडिंग नहीं। भिन्न विभाजक दोनों निर्माणों को डोमेन-पृथक करता है, इसलिए एक प्रीइमेज पर किया गया हस्ताक्षर कभी भी दूसरे के रूप में सत्यापित नहीं हो सकता।

org_id_present बाइट: unlock_at के बाद आने वाला बाइट 0x00 होना MUST। संदर्भ कार्यान्वयन इसे crates/qub-core/src/signing.rs में स्थिर ORG_ID_PRESENT_INDIVIDUAL = 0x00 के रूप में उजागर करता है; सत्यापन के लिए sig_input का पुनर्निर्माण करने वाले दर्शक उसी बाइट को उत्सर्जित करना MUST।

हस्ताक्षर दायरा — क्या कवर है और क्या नहीं। V2 sig_input सीधे version, qub_id, body_hash, unlock_at, sender_label, और reply_to के लिए प्रतिबद्ध होता है (साथ ही स्थिर डोमेन विभाजक और org_id_present बाइट)। qub_id स्वयं §4.1 प्रीइमेज के माध्यम से version, content_type, created_at, unlock_at, outcome_at, drand_round, और body_hash से व्युत्पन्न होता है, इसलिए उन क्षेत्रों में कोई भी परिवर्तन एक अलग qub_id उत्पन्न करता है और सकर्मक रूप से हस्ताक्षर को अमान्य कर देता है। इसलिए प्रमाणित सतह है:

V2 ही एकमात्र स्वीकृत प्रीइमेज क्यों है।

• वापस ली गई V1 प्रीइमेज के अंतर्गत, संग्रहीत बाइट्स तक राइट एक्सेस वाला कोई पक्ष लेखक के हस्ताक्षर को अमान्य किए बिना sender_label ("ऐलिस" → "मैलोरी") को बदल सकता था या reply_to को फिर से पैरेंट कर सकता था — और राउंड के बाद फिर से एन्क्रिप्ट कर सकता था — क्योंकि इनमें से कोई भी क्षेत्र हस्ताक्षरित प्रीइमेज में नहीं था। V2 दोनों को कवर करता है, इसलिए किसी भी क्षेत्र में कोई भी परिवर्तन सत्यापन को "विफल" पर पलट देता है। चूँकि सत्यापनकर्ता अब केवल V2 स्वीकार करते हैं, यह अदला-बदली हर हस्ताक्षर के लिए बंद हो जाती है: जो हस्ताक्षर किसी भी क्षेत्र को नहीं बांधता (अर्थात केवल V1 के विरुद्ध सत्यापित होता है) उसे डाउनग्रेड करने के बजाय सीधे अस्वीकार कर दिया जाता है।
• एनवेलप के अंदर author_pubkey सच्चा पहचान लंगर बना रहता है — दर्शक sender_label पर भरोसा करने के बजाय author_pubkey से (§9.5 अनुप्रमाणन परत के माध्यम से) प्रदर्शन पहचान व्युत्पन्न करना MUST।

जो कार्यान्वयन अंतिम उपयोगकर्ताओं को sender_label या reply_to प्रदर्शित करते हैं, उन्हें प्राथमिक पहचान संकेत के रूप में प्रमाणित पहचान (पबकी फ़िंगरप्रिंट, अनुप्रमाणन) को सतह पर लाना MUST, लेबल को नहीं।

9.4 सत्यापन प्रक्रिया

1. Read sig_alg from QubEnvelope.
2. If sig_alg == 0x00 → unsigned. No verification. Display "unsigned qub."
3. If sig_alg is unknown → reject. Display "unrecognised signature scheme."
4. Extract author_signature and author_pubkey. If either is absent → integrity error.
5. Reconstruct sig_input using fields from QubEnvelope (V2 formula, §9.3).
6. Verify(author_pubkey, sig_input, author_signature). The V2 preimage is the
   only accepted form — the legacy V1 fallback is retired (§9.3), so a
   signature that does not verify against V2 fails, full stop.
7. If verification succeeds → display "signed by [key fingerprint]."
8. If verification fails → display "signature verification failed."

हस्ताक्षर सत्यापन सबसे महंगा ऑपरेशन है (विशेष रूप से ML-DSA-65)। इसे सभी सस्ती जाँचों (हैश, qub_id, unlock_at) के पारित होने के बाद ही किया जाना SHOULD।

9.5 पहचान अनुप्रमाणन

पहचान अनुप्रमाणन — author_pubkey का मानव-पहचानने योग्य पहचान दावों जैसे qub हैंडल, ईमेल पता, सोशल हैंडल, या पासकी क्रेडेंशियल से मानचित्रण — एक दर्शक-पक्ष प्रगतिशील संवर्धन है और हस्ताक्षर सत्यापन के लिए आवश्यक नहीं है। प्रदर्शन पहचान के लिए अनुप्रमाणन हल करने वाले दर्शक वरीयता क्रम लागू करना MUST:

handle > email > social > fingerprint

फ़िंगरप्रिंट फ़ॉलबैक SHA3-256(author_pubkey) का लोअरकेस हेक्स है; यह किसी भी हस्ताक्षरित qub के लिए हमेशा उपलब्ध है। दर्शक प्रदर्शन के लिए इसे संक्षिप्त करना MAY — संदर्भ दर्शक qub: के बाद पहले और अंतिम चार बाइट्स (qub:<8 hex>…<8 hex>) रेंडर करता है।

एक अनुरूप सत्यापनकर्ता qub API से संपर्क किए बिना, स्थायी संग्रहण और drand से परे किसी भी नेटवर्क के बिना, और किसी भी सर्वर-साइड लुकअप के बिना §9.4 में हर जाँच पूरी कर सकता है। अनुप्रमाणन समाधान केवल हस्ताक्षर सत्यापन सफल होने के बाद किया गया एक अलग सर्वोत्तम-प्रयास चरण है।

9.6 आकार प्रभाव

500–2,000 बाइट्स के टेक्स्ट qub के लिए, ML-DSA-65 लगभग संग्रहीत आकार को तिगुना कर देता है। निरपेक्ष लागत नगण्य है।

9.7 सह-हस्ताक्षरकर्ता सत्यापन (संधि द्विपक्षीय समझौते)

द्विपक्षीय समझौतों (content_type = 0x03) के लिए, एक दूसरी हस्ताक्षर परत प्रमाणित करती है कि दोनों पक्षों ने समान शर्तों के लिए सहमति दी।

एनवेलप क्षेत्र:

• cosigner_pubkey: प्रति-हस्ताक्षरकर्ता (पक्ष B) की ML-DSA-65 सार्वजनिक कुंजी।
• cosigner_signature: लेखक के समान sig_input पर हस्ताक्षर (§9.3)।

दोनों क्षेत्र एक साथ उपस्थित MUST या दोनों अनुपस्थित। यदि ठीक एक उपस्थित है, तो दर्शक अखंडता त्रुटि की रिपोर्ट करना MUST।

सत्यापन प्रक्रिया:

1. If cosigner_pubkey absent and cosigner_signature absent → no cosigner. Done.
2. If exactly one is present → integrity error.
3. Verify cosigner_pubkey != author_pubkey (prevent self-cosigning).
   Fail → display "cosigner pubkey must differ from author."
4. Reconstruct sig_input using the same formula as §9.3 (V2 only — the
   legacy V1 fallback is retired; all pact clients produce V2 signatures).
5. Verify(cosigner_pubkey, sig_input, cosigner_signature).
6. Success → display "co-signed by [cosigner fingerprint]."
7. Failure → display "co-signature verification failed."

गुण:

• सह-हस्ताक्षरकर्ता लेखक के समान sig_input पर हस्ताक्षर करता है — दोनों पक्ष समान qub_id, body_hash, और unlock_at (और, V2 के अंतर्गत, समान sender_label_hash और reply_to_or_zero) के लिए प्रतिबद्ध होते हैं।
• प्रति-हस्ताक्षरकर्ता को कच्चे एनवेलप बाइट्स तक पहुँच के बिना V2 प्रीइमेज का पुनर्निर्माण करने में सक्षम बनाने के लिए, स्टेजिंग सेवा स्टेज समय पर यह लागू करती है कि एक संधि एनवेलप का sender_label pact_terms.party_a.label के बराबर हो और reply_to अनुपस्थित हो। संदर्भ-क्लाइंट की प्रत्येक संधि के लिए दोनों धारण करते हैं; उल्लंघन करने वाले एनवेलप स्टेजिंग पर अस्वीकार कर दिए जाते हैं।
• qub_id व्युत्पत्ति (§4.1) में सह-हस्ताक्षरकर्ता क्षेत्र शामिल नहीं हैं। मौजूदा एनवेलप में सह-हस्ताक्षरकर्ता जोड़ने से qub_id नहीं बदलता।
• एक संधि केवल लेखक-हस्ताक्षरित (एकतरफा प्रतिबद्धता), केवल सह-हस्ताक्षरकर्ता (असामान्य), या दोनों (पूर्ण द्विपक्षीय प्रमाण) हो सकती है।

ईमेल-बंधन गेट (परिचालन)। जब एक स्टेज की गई संधि एक पक्ष B ईमेल संपर्क (§6.1) ले जाती है, तो qub अपलोड सेवा सह-हस्ताक्षर अनुरोध को अस्वीकार करना MUST जब तक कि एक अल्पकालिक ईमेल-सत्यापन मार्कर मौजूद न हो जो स्टेजिंग id और उस संपर्क के सामान्यीकृत-ईमेल हैश दोनों से मेल खाता हो। मार्कर /api/v1/auth/verify द्वारा लिखा जाता है जब मैजिक-लिंक टोकन staging_id ले जाता है और सत्यापित पता SHA-256(normalise_email(party_b.contact)) से मेल खाता है — जहाँ normalise_email(addr) स्थानीय-भाग के केस को संरक्षित करता है और केवल डोमेन भाग को लोअरकेस करता है (RFC 5321 §2.3.11 के अनुसार), और SHA-256 यहाँ NIST FIPS 180-4 हैश है (§4 व्युत्पत्तियों में उपयोग किए जाने वाले SHA3-256 से अलग) — और जारी होने के 900 सेकंड (15 मिनट) बाद समाप्त हो जाता है। यह एक परिचालन प्रति-प्रतिरूपण गेट है, ऑन-चेन qub प्रमाण का हिस्सा NOT — एक तृतीय-पक्ष सत्यापनकर्ता जो §11 को रिप्ले कर रहा है, उसे केवल स्थायी संग्रहण और drand की आवश्यकता होती है, बिना किसी सर्वर-साइड लुकअप के। मार्कर केवल सर्वर-साइड मौजूद है और हस्ताक्षरित बॉडी का हिस्सा कभी नहीं होता।

आकार प्रभाव (ML-DSA-65 लेखक + सह-हस्ताक्षरकर्ता):

10. मार्कडाउन रेंडरिंग और स्वच्छीकरण

यह अनुभाग सुरक्षा-गंभीर है। दर्शक एक प्रतिबंधित मार्कडाउन उपसमुच्चय का उपयोग करके टेक्स्ट qubs (content_type = 0x01) को रेंडर करता है।

10.1 अनुमत तत्व

• शीर्षक: # से #### तक (कोई ##### या ###### नहीं)
• ज़ोर: बोल्ड (**), इटैलिक (*), स्ट्राइकथ्रू (~~)
• सूचियाँ: क्रमबद्ध (1.) और अक्रमबद्ध (-, *)
• ब्लॉकउद्धरण (>)
• कोड: इनलाइन स्पैन (```) और बाड़ लगाए गए ब्लॉक (`````)
• क्षैतिज नियम (---)
• पंक्ति विराम (दो ट्रेलिंग रिक्त स्थान या रिक्त पंक्ति)
• अनुच्छेद

10.2 निषिद्ध तत्व

10.3 कार्यान्वयन

कार्यान्वयन एक सख्त अनुमति-सूची पार्सर का उपयोग करना MUST, अवरुद्ध-सूची का नहीं। अनुशंसित दृष्टिकोण:

1. pulldown-cmark (या समकक्ष) का उपयोग करके मार्कडाउन पार्स करें।
2. AST के माध्यम से चलें और अनुमति-सूची (§10.1) में नहीं किसी भी नोड को छोड़ दें।
3. लिंक नोड्स के लिए: URL को दृश्यमान टेक्स्ट के रूप में उत्सर्जित करें, क्लिक करने योग्य <a> तत्व के रूप में नहीं।
4. फ़िल्टर किए गए AST को एक टाइप्ड मध्यवर्ती प्रतिनिधित्व (उदा. केवल सुरक्षित वैरिएंट्स के साथ एक MarkdownNode enum) में परिवर्तित करें। इस IR में कच्चा HTML संरचनात्मक रूप से अप्रतिनिधित्व योग्य है।
5. टाइप्ड IR से लक्ष्य व्यू परत (उदा. प्रतिक्रियाशील व्यू घटक, DOM नोड्स) में रेंडर करें। किसी भी बिंदु पर कोई HTML स्ट्रिंग संयोजन या innerHTML नहीं।

अवरुद्ध-सूची दृष्टिकोण नाजुक हैं क्योंकि नए मार्कडाउन एक्सटेंशन या पार्सर विचित्रताएँ अनफ़िल्टर्ड तत्वों को पेश कर सकती हैं। टाइप्ड-AST दृष्टिकोण XSS को संरचनात्मक रूप से असंभव बनाता है — कोई वैरिएंट नहीं है जो मनमाने HTML को ले जा सके।

10.4 आकार और संरचना सीमाएँ

• अधिकतम रेंडर किया गया शीर्षक गहराई: #### (H4)। ##### और गहरे बोल्ड टेक्स्ट के रूप में रेंडर किए जाते हैं।
• अनुच्छेद गणना पर कोई सीमा नहीं (§6 में बॉडी आकार सीमाएँ बाधा हैं)।
• बाड़ लगाए गए कोड ब्लॉक: MVP में कोई सिंटैक्स हाइलाइटिंग नहीं। मोनोस्पेस पूर्व-प्रारूपित टेक्स्ट के रूप में रेंडर।

11. तृतीय-पक्ष सत्यापन

संग्रहीत बाइट्स (और निजी/रैप्ड qub के लिए K) रखने वाला कोई भी तृतीय पक्ष qub के सहयोग के बिना क्रिप्टोग्राफिक artifact सत्यापित कर सकता है। स्वतंत्र रूप से समय-मुद्रित अस्तित्व दावे के लिए अतिरिक्त रूप से या तो सत्यापित प्रति-qub स्थायी-संग्रहण समावेशन या सत्यापित §16 पारदर्शिता-लॉग प्रमाण आवश्यक है।

1. Obtain the stored bytes. For a private delivery, also obtain K from the
   delivery-link fragment.
2. Resolve the delivery shape (§8 step 3a): unwrap OuterWrapper with K, or
   accept bare SealedQubCbor. Require shape/visibility agreement.
3. Parse SealedQubCbor → SealedQub; validate protocol version, visibility,
   content type, chain identity, and structural bounds.
4. Recompute expected_round from unlock_at (§4.3); require the stored round
   (allowing the documented legacy minus-one case) and ciphertext-stanza round
   to agree exactly as §8 step 6a specifies.
5. Obtain the drand signature for SealedQub.drand_round and verify its BLS
   signature against the pinned chain public key.
6. tlock_decrypt(tlock_ciphertext, round_signature) → QubEnvelope CBOR bytes.
7. Parse → QubEnvelope.
8. Verify SHA3-256(body) == body_hash.
9. Verify envelope/sealed equality for qub_id, unlock_at, and outcome_at.
10. Recompute qub_id from the decrypted fields, sealed drand_round, and title;
    require it to equal the carried qub_id (§4.1).
11. If sig_alg != 0x00, verify the V2 author signature (§9.4). If cosigner
    fields are present, verify their pairing, key separation, and signature
    (§9.7).
12. For an existence-time claim, independently verify either:
    a. the permanent-storage transaction's data-to-id binding, owner, block
       inclusion, and block timestamp; or
    b. a §16 inclusion proof through its pinned anchor and anchor block time.
13. Report each verified claim separately; do not collapse an absent storage
    or anchor proof into a successful timing verdict.

सत्यापन क्या प्रमाणित करता है:

सत्यापन क्या प्रमाणित नहीं करता:

कार्यान्वित पारदर्शिता लॉग (§16) tamper-evident क्रम और trustless ऊपरी-सीमा प्रतिबद्धता समय (anchor block time) से qubs के बीच सत्यापन बढ़ाता है, जिसे leaf kind (§16.11) द्वारा सीमित किया गया है। यह लेखकत्व या इरादा नहीं जोड़ता; डिफ़ॉल्ट byte-blind upload path के लिए यह स्वयं body_hash या drand_round सिद्ध नहीं करता, जो artifact checks से मिलते हैं।

12. संस्करण और रिलीज़ नियंत्रण

दस्तावेज़ रिलीज़, आंतरिक wire protocol और बाहरी wrapper अलग version spaces हैं। इसलिए केवल-दस्तावेज़ स्पष्टीकरण चुपचाप bytes नहीं बदलता और भविष्य का wire migration editorial revision का रूप नहीं ले सकता।

12.1 दस्तावेज़ रिलीज़ संस्करण

यह विनिर्देशन semantic document releases (MAJOR.MINOR.PATCH) और protocol-v<release> नाम के immutable Git tag का उपयोग करता है।

• PATCH: सटीकता या editorial सुधार जो अनुरूप bytes या आवश्यक behavior नहीं बदलता।
• MINOR: backward-compatible normative addition, नई registry entry या नया स्वतंत्र version वाला sidecar format।
• MAJOR: incompatible normative change, जिसमें नई आवश्यक wire interpretation शामिल है।

Release status मसौदा (अभी normative नहीं), वर्तमान (एकमात्र अनुशंसित implementation target), या प्रतिस्थापित (historical verification के लिए रखा गया) में से एक है। Unversioned /protokol route वर्तमान release दिखाता है; release tag उसका exact source और उसके साथ प्रकाशित हर locale सुरक्षित रखता है। Status या release number बदलने के लिए इसी reviewed change में यह table और release history अपडेट करना आवश्यक है।

12.2 प्रोटोकॉल संस्करण

SealedQub और QubEnvelope दोनों में version क्षेत्र (u8) मुख्य प्रोटोकॉल संस्करण की पहचान करता है।

• दर्शक एक स्पष्ट त्रुटि के साथ अज्ञात प्रमुख संस्करणों को अस्वीकार करना MUST।
• एक ज्ञात प्रमुख संस्करण के भीतर, डिकोडर अज्ञात मानचित्र कुंजियों को अस्वीकार करना MUST (§3.1) — योजना का विकास एक नया version प्रस्तुत करने से होता है, ऐसी कुंजियाँ जोड़ने से नहीं जिन्हें मौजूदा डिकोडर छोड़ देते। (इस विनिर्देशन के पहले के संशोधन अज्ञात वैकल्पिक क्षेत्रों को सहन करने की अनुमति देते थे; वह खंड वापस ले लिया गया है — यह encode(decode(x)) को गैर-इंजेक्टिव बना देता था और संधि पेलोड पर एक छिपी-हस्ताक्षरित-सामग्री सदिश खोल देता था।)
• सामग्री प्रकार (content_type) और हस्ताक्षर योजनाएँ (sig_alg) संस्करण-नियंत्रित हैं: नए मान केवल एक नए प्रोटोकॉल संस्करण या स्पष्ट रजिस्ट्री अद्यतन के साथ ही प्रस्तुत किए जा सकते हैं।

12.3 प्रोटोकॉल संस्करण इतिहास

12.4 फ़ॉरवर्ड संगति

एक v1 दर्शक जो अज्ञात CBOR मानचित्र कुंजियों (§3.2 कैनोनिकल क्रम में नहीं की कुंजियाँ) के साथ QubEnvelope का सामना करता है, उसे एक डिकोड त्रुटि के साथ अस्वीकार करना MUST (§3.1)। फ़ॉरवर्ड संगति version क्षेत्र पर टिकी है, कुंजी सहनशीलता पर नहीं: भविष्य के जोड़ — छोटे मेटाडेटा भी — एक नए version मान के तहत आते हैं, जिसे एक v1 दर्शक एक स्पष्ट "नया प्रोटोकॉल" त्रुटि के साथ अस्वीकार करता है — बजाय इसके कि वह उस सामग्री को चुपचाप गिरा दे जिसके लिए हस्ताक्षर प्रतिबद्ध होते हैं।

एक v1 दर्शक जो sig_alg = 0x01 (ML-DSA-65) का सामना करता है लेकिन ML-DSA-65 सत्यापन समर्थन की कमी है, qub सामग्री को "हस्ताक्षर उपस्थित लेकिन सत्यापन योग्य नहीं" सूचना के साथ प्रदर्शित करना SHOULD, qub को पूरी तरह से अस्वीकार नहीं करना। संदर्भ कार्यान्वयन आज 0x00 और 0x01 के अलावा हर sig_alg मान को अस्वीकार करता है क्योंकि v1 रजिस्ट्री में कोई अन्य मान्य एल्गोरिथम नहीं है — सख्त अस्वीकृति और सॉफ्ट-फ़ेल तब तक अवलोकनात्मक रूप से समान हैं जब तक कि एक तीसरा एल्गोरिथम पंजीकृत न हो। ऊपर का सॉफ्ट-फ़ेल व्यवहार तब भार-वहन करने वाला हो जाता है जब §9.2 एक नई प्रविष्टि स्वीकार करता है, और संदर्भ दर्शक उस बिंदु पर सॉफ्ट-फ़ेल करने के लिए अद्यतन किया जाएगा।

12.5 बाहरी आवरण संस्करण

§13 में वर्णित OuterWrapper अपना स्वयं का version बाइट ले जाता है, स्वतंत्र SealedQub.version और QubEnvelope.version से। दो संस्करण स्थान अलग-अलग विकसित होते हैं: एक भविष्य का उत्तर-क्वांटम-सुरक्षित सममित प्रतिस्थापन आंतरिक प्रोटोकॉल संस्करण को छुए बिना आवरण बाइट को उछालता है, और एक भविष्य का प्रोटोकॉल-परत जोड़ (उदा. एक नया एनवेलप क्षेत्र) आवरण बाइट को छुए बिना आंतरिक संस्करण को उछालता है।

दर्शक अज्ञात आवरण संस्करणों को एक स्पष्ट त्रुटि के साथ अस्वीकार करना MUST। प्रोटोकॉल जानबूझकर आवरण संस्करण स्थान को संकीर्ण रखता है जब तक कि एक ठोस माइग्रेशन चालक प्रकट नहीं होता (उदा. एक अलग AEAD के पक्ष में NIST मार्गदर्शन); एक 0x02 स्लॉट उसी संशोधन में आवंटित किया जाएगा जो एल्गोरिथम का परिचय देता है।

13. बाहरी एन्क्रिप्शन आवरण

13.1 तर्क

प्रोटोकॉल परतें (QubEnvelope → tlock → SealedQub) एक मुहरबंद qub को समय-बद्ध बनाती हैं: बॉडी unlock_at तक अपठनीय है और drand राउंड हस्ताक्षर प्रकाशित हो चुका है। हालाँकि, अनलॉक के बाद, राउंड हस्ताक्षर सार्वजनिक है और SealedQub का कैनोनिकल CBOR आकार पहचानने योग्य है, इसलिए एक हार्वेस्टर जिसने स्थायी-संग्रहण लेन-देन को अनुक्रमित किया है, संपूर्ण qub कॉर्पस को थोक-डिक्रिप्ट कर सकता है।

निजी डिलीवरी के लिए बाहरी एन्क्रिप्शन wrapper canonical SealedQubCbor और संग्रहीत बाइट्स के बीच अतिरिक्त सिमेट्रिक AEAD परत डालकर उस चैनल को बंद करता है। Browser-seal path में 256-बिट कुंजी K डिलीवरी URL के fragment और user devices पर केवल रहती है; browser URL fragments server को नहीं भेजते, इसलिए qub.social, हर storage gateway और उनके सामने हर CDN K से अनभिज्ञ हैं। निजी qub का संग्रहीत रूप इसलिए opaque ciphertext है जिसका plaintext रचयिता द्वारा साझा किए गए URL के बिना अप्राप्य है। सार्वजनिक डिलीवरी जानबूझकर यह परत छोड़ देती है (§13.8)।

शुद्ध प्रभाव:

• निजी डिलीवरी के लिए गणन प्रतिरोध। OuterWrapper पहचाने जा सकने वाला संरचित CBOR रहता है—यह वास्तव में यादृच्छिक बाइट्स से अप्रभेद्य नहीं है—लेकिन उसका सिफरटेक्स्ट फ़ील्ड पहचाने जा सकने वाले आंतरिक SealedQub आकार को छिपाता है। “नंगे qub-आकार के अपलोड के लिए GraphQL क्वेरी करें और सार्वजनिक drand हस्ताक्षरों से थोक में डिक्रिप्ट करें” की प्रलेखित हार्वेस्टर रणनीति K के बिना प्लेनटेक्स्ट तक नहीं पहुँचती।
• डिफ़ॉल्ट निजी ब्राउज़र फ़्लो के लिए क्रिप्टो-श्रेडिंग गोपनीयता मुद्रा। qub.social अपने डिफ़ॉल्ट सर्वर-साइड डेटा से उन संग्रहीत आर्टिफ़ैक्ट को डिक्रिप्ट नहीं कर सकता। स्पष्ट रिकवरी, सार्वजनिक डिलीवरी और विश्वसनीय सर्वर-साइड मुहरबंदी की अलग-अलग प्रकट की गई विश्वास सीमाएँ हैं।
• दो-स्तरीय गोपनीयता सीढ़ी। डिफ़ॉल्ट = लिंक-नियंत्रित पहुँच (यह अनुभाग)। प्राप्तकर्ता-एन्क्रिप्टेड निजी qubs (एक आरक्षित Phase-2 सुविधा, अभी तक निर्दिष्ट नहीं) दूसरे स्तर के रूप में शीर्ष पर परत बनाते हैं।

13.2 परतीकरण

plaintext body                       ← QubEnvelope.body (§2.2)
  ↓ canonical CBOR (§3)
envelope CBOR
  ↓ tlock encrypt to drand round (§7 step 10)
tlock_ciphertext (inside SealedQub) (§2.3)
  ↓ canonical CBOR (§3)
SealedQubCbor bytes                  ← inner wire artifact
  ├─ public (visibility=0x01) ───────────────▶ stored directly (§13.8)
  └─ private (visibility=0x00)
       ↓ AES-256-GCM(K, nonce, AAD=qub_id) (§7 step 12, this section)
     OuterWrapper CBOR bytes         ← stored private payload

प्रोटोकॉल परत (§7, §8) पर मुहरबंदी और अनलॉक आवरण सीमा के नीचे अपरिवर्तित हैं; आवरण seal() के कॉल साइट पर जुड़ता है और unlock() के कॉल साइट पर अलग होता है।

13.3 OuterWrapper डेटा संरचना

struct OuterWrapper {
    version:    u8,           // 0x01, see §12.5
    qub_id:     [u8; 32],     // copied from inner SealedQub; AEAD AAD
    nonce:      [u8; 12],     // 96-bit AEAD nonce
    ciphertext: Vec<u8>,      // AES-256-GCM(K, nonce, SealedQubCbor, AAD=qub_id) || 16-byte tag
}

क्षेत्र अपरिवर्तनीय।

• version v1.0 आवरण बाइट्स के लिए 0x01 के बराबर होना MUST।
• qub_id अनरैपिंग के बाद पुनर्प्राप्त SealedQub के qub_id क्षेत्र के बराबर होना MUST। संदर्भ wrap_sealed_qub और unwrap_sealed_qub, दोनों आंतरिक CBOR को पार्स करके इस समानता को सीधे लागू करते हैं; AAD बंधन अलग से यह सुनिश्चित करता है कि रैप करने के बाद बाहरी qub_id से छेड़छाड़ करने पर प्रमाणीकरण विफल हो जाए।
• nonce 96 बिट (12 बाइट्स) होना MUST, प्रत्येक रैप ऑपरेशन के लिए एक CSPRNG द्वारा ताज़ा उत्पन्न किया गया। एक ही कुंजी के तहत एक nonce का पुन: उपयोग AEAD nonce-पुन: उपयोग हमलों की अनुमति देता है जो प्लेनटेक्स्ट को पुनर्प्राप्त करते हैं; उत्पादक (key, nonce) जोड़ों को एक-शॉट के रूप में मानना MUST।
• ciphertext AES-256-GCM आउटपुट है: 16-बाइट प्रमाणीकरण टैग के साथ संयोजित सिफरटेक्स्ट बाइट्स। ciphertext.len() == SealedQubCbor.len() + 16 ठीक।

CBOR एन्कोडिंग। §3 के अनुसार कैनोनिकल CBOR, उसी कुंजी-क्रम नियम के साथ (एन्कोडेड बाइट लंबाई आरोही द्वारा क्रमबद्ध, फिर शब्दकोश)। चार कुंजियाँ हैं:

OuterWrapper CBOR का पहला बाइट इसलिए 4-प्रविष्टि मानचित्र (0xA4) के लिए निश्चित-लंबाई मानचित्र हेडर है।

13.4 qub_id के लिए AAD बंधन

आवरण qub_id को AEAD अतिरिक्त प्रमाणित डेटा के रूप में बांधता है। यह तीन वर्ग के हमलों के विरुद्ध भार-वहन करने वाली संरचनात्मक रक्षा है:

आवरण प्लेनटेक्स्ट में qub_id ले जाना गणन प्रतिरक्षा को सार्थक रूप से कमज़ोर नहीं करता — qub_id स्वयं §4.1 प्रीइमेज का SHA3-256 हैश है जिसमें डाइजेस्ट से कोई पुनर्प्राप्ति योग्य प्रीइमेज नहीं है, और एक गणक जिसने पहले से आवरण बाइट्स को काटा है, दृश्यमान qub_id से कुछ नहीं सीखता जो वे अपलोड के अस्तित्व से अनुमान नहीं लगा सकते।

13.5 रैप और अनरैप एल्गोरिथम

wrap_sealed_qub(SealedQubCbor S, qub_id Q, key K, nonce N):
    require K.len() == 32 and N.len() == 12 and Q.len() == 32
    I := canonical_cbor_decode(S) as SealedQub
    require I.qub_id == Q               // reject mismatched caller AAD
    C := AES_256_GCM_encrypt(key=K, nonce=N, msg=S, aad=Q)
    // C includes the 16-byte authentication tag at the end
    return canonical_cbor_encode(OuterWrapper{
        version:    0x01,
        qub_id:     Q,
        nonce:      N,
        ciphertext: C,
    })

unwrap_sealed_qub(OuterWrapper bytes W, key K):
    require K.len() == 32
    O := canonical_cbor_decode(W) as OuterWrapper
    require O.version == 0x01           // §12.5
    P := AES_256_GCM_decrypt(
            key=K, nonce=O.nonce, ciphertext=O.ciphertext, aad=O.qub_id
         )
    // any AEAD failure → DECRYPT_FAILED, indistinguishable to caller
    S := canonical_cbor_decode(P) as SealedQub
    require S.qub_id == O.qub_id       // explicit inner/outer cross-check
    return P                            // P is the validated SealedQubCbor

विफलता-मोड पतन। ग़लत K, ग़लत nonce, AAD बेमेल, और छेड़छाड़ किया गया सिफरटेक्स्ट सभी एक ही DECRYPT_FAILED त्रुटि उत्पन्न करते हैं। यह एक जानबूझकर AEAD गुण है: विफलता मोड को अलग करने से एक साइड चैनल बनेगा जिसे एक दूरस्थ हमलावर विकृत आवरण भेजकर और प्रतिक्रिया को समयित करके जाँच सकता है। संदर्भ कार्यान्वयन सभी AEAD विफलताओं को एकल त्रुटि आकार में संक्षेपित करना MUST।

13.6 कुंजी सामग्री और वितरण

रैपिंग कुंजी K एक प्रति-qub CSPRNG द्वारा उत्पन्न एक 256-बिट समान यादृच्छिक मान है। संदर्भ कार्यान्वयन इसे यहाँ से प्राप्त करते हैं:

• WASM रचयिता: getrandom (wasm_js बैकएंड के तहत WebCrypto)।
• सर्वर-साइड seal API कॉलर: इसका स्थानीय CSPRNG; कॉलर K की आपूर्ति करता है और उसे wrapper_key_b64url के रूप में बनाए रखता है। Worker आवरण के लिए K का उपयोग मेमोरी में करता है लेकिन उसे संरक्षित करना MUST NOT। यह एक idempotent पुनः प्रयास को, एक-बारगी सर्वर-जनित गुप्त मान पर निर्भर होने के बजाय कॉलर की बनाए रखी गई क्षमता का उपयोग करके, एक संपादित प्रतिक्रिया पुनर्प्राप्त करने देता है।

वितरण: K को URL-सुरक्षित base64 (RFC 4648 §5, कोई पैडिंग नहीं) के रूप में एन्कोड किया जाना MUST और फ़्रैगमेंट घटक के रूप में डिलीवरी URL में जोड़ा जाना MUST:

delivery_url = <origin>/c/<arweave_tx_id>#<base64url(K)>

फ़्रैगमेंट को किसी भी सर्वर को एक अनुरूप ब्राउज़र द्वारा कभी संचारित नहीं किया जाता। पुनर्प्राप्ति चैनल (सर्वर-साइड इतिहास सूचकांक, ऑप्ट-इन ईमेल ऑटो-सेंड) जो उपयोगकर्ता डिवाइस से परे पूर्ण डिलीवरी URL — फ़्रैगमेंट सहित — को बनाए रखते हैं, डिफ़ॉल्ट क्रिप्टो-श्रेडिंग मुद्रा के विरुद्ध एक स्पष्ट व्यापार हैं और स्पष्ट उपयोगकर्ता सहमति पर गेट किए जाने MUST।

फ़्रैगमेंट हानि। यदि एक उपयोगकर्ता URL फ़्रैगमेंट खो देता है और कोई पुनर्प्राप्ति चैनल नहीं है, तो qub अपठनीय है। यह डिज़ाइन का भार-वहन करने वाला व्यापार है और मुहरबंदी समय पर उपयोगकर्ता को प्रकट किया जाना MUST। MVP मुहरबंदी-समय प्रकटीकरण को स्पष्ट "इस URL को सहेजें" प्रति और ऑप्ट-इन करने वाले उपयोगकर्ताओं के लिए एक सत्यापित-ईमेल पुनर्प्राप्ति चैनल के साथ मज़बूत करता है।

13.7 इस अनुभाग के लिए दायरे से बाहर

• लेखकत्व हस्ताक्षर (§9) अपरिवर्तित है: हस्ताक्षर आंतरिक QubEnvelope के अंदर गणना किए जाते हैं और अनरैप → tlock डिक्रिप्ट → CBOR पार्स के बाद पुनर्प्राप्त किए जाते हैं।
• Recipient-public-key encryption (आरक्षित recipient_pubkey फ़ील्ड) आज के निजी, link-capability-gated wrapper mode से अलग भविष्य की सुविधा है।
• वर्तमान server-side pact co-sign flow visibility 0x01 के साथ सार्वजनिक/बिना-wrapper SealedQubCbor निकालता है; वह browser-only K-secrecy model पूरा नहीं कर सकता क्योंकि अंतिम मुहरबंदी server-mediated co-sign के बाद होती है। भविष्य का private-pact producer इसी wrapper का उपयोग कर सकता है, जो inner content type से byte-blind है।

13.8 सार्वजनिक qubs (आवरण लोप)

बाहरी आवरण वितरण परत पर वैकल्पिक है। एक रचयिता qub को सार्वजनिक रूप में मुहरबंद कर सकता है, जिस स्थिति में कैनोनिकल SealedQubCbor बिना किसी OuterWrapper परत और बिना कुंजी K के संग्रहण पाइपलाइन में सीधे प्रवेश करता है:

SealedQubCbor bytes  ──(public)──▶  stored as-is
SealedQubCbor bytes  ──(private)─▶  AES-256-GCM(K, …) ▶ OuterWrapper ▶ stored

एक सार्वजनिक qub समय-बद्ध है लेकिन लिंक-नियंत्रित नहीं: यह तब तक अपठनीय रहता है जब तक इसका drand राउंड प्रकाशित नहीं हो जाता (tlock परत अपरिवर्तित है), लेकिन अनलॉक के बाद storage transaction id रखने वाला कोई भी व्यक्ति इसे डिक्रिप्ट कर सकता है — किसी URL फ़्रैगमेंट की आवश्यकता नहीं, क्योंकि कोई K नहीं है। यह उन सतहों के लिए जानबूझकर किया गया trade-off है जिन्हें सर्वर को चलाना MUST: reveal-notification ईमेल, fragment-रहित oEmbed/auto-embed लिंक और अधिक समृद्ध post-reveal SEO को ऐसे लिंक की आवश्यकता है जो उस रहस्य के बिना काम करे जिसे सर्वर कभी धारण नहीं करता (§13.6)। निजी qub स्पष्ट <qub-embed src="full_delivery_url"> रूप का उपयोग तब भी कर सकता है जब प्रकाशक उसकी पूरी fragment-bearing capability देता है।

परिणाम जिनके लिए एक उत्पादक को MUST हिसाब रखना:

• कोई गणन प्रतिरक्षा नहीं। सार्वजनिक qubs रचना द्वारा §13.1 गणन-प्रतिरक्षा गुण को त्याग देते हैं। संदर्भ अपलोड सेवा उन पर (और केवल उन पर) एक Visibility: public स्थायी-संग्रहण टैग मुद्रित करती है ताकि वे जानबूझकर खोजने योग्य हों; निजी qubs ऐसा कोई टैग नहीं ले जाते और अपनी बाइट-अप्रभेद्यता बनाए रखते हैं।
• मुहरबंदी समय पर उजागर प्लेनटेक्स्ट शीर्षक। §3.2 title क्षेत्र SealedQubCbor के अंदर प्लेनटेक्स्ट है। आवरण के तहत यह तब तक छिपा रहता है जब तक एक दर्शक K प्रदान नहीं करता; आवरण के बिना यह स्थायी संग्रहण पर अपलोड के क्षण से, अनलॉक से पहले, विश्व-पठनीय है। अनुरूप रचयिता ऐप्स इसे मुहरबंदी समय पर प्रकट करना MUST।
• पहचान संरचनात्मक है और cross-check की जाती है। अनुरूप viewer/embed stored shapes को parse से अलग करता है: OuterWrapper के रूप में parse होने वाली bytes K से unwrap path लेती हैं; bare SealedQubCbor के रूप में parse होने वाली bytes सीधे स्वीकार होती हैं। recovered inner value सहमत होना MUST (0x00 wrapped/private, 0x01 bare/public)। qub_id visibility को नहीं बाँधता, लेकिन canonical SealedQub bytes उसे रखती हैं, इसलिए public और private inner encodings byte-identical नहीं हैं।

निजी (रैप किया हुआ) डिफ़ॉल्ट बना रहता है; सार्वजनिक एक स्पष्ट प्रति-qub रचयिता विकल्प है।

14. परीक्षण सदिश

14.1 qub_id व्युत्पत्ति

Input:
  version      = 0x01
  content_type = 0x01
  created_at   = 1735689600 (2025-01-01 00:00:00 UTC)
  unlock_at    = 1736294400 (2025-01-08 00:00:00 UTC)
  outcome_at   = absent
  drand_round  = 4695446  (= floor((1736294400 - 1595431050) / 30) + 1, §4.3 mapping, drand mainnet params §14.2)
  body         = "Hello, future."  (UTF-8, 14 bytes)
  title        = absent

Intermediate:
  body_hash  = SHA3-256("Hello, future.")
             = 76ab8b3f843c6ed4f2d0fd75b9f457b4
               ad49dd4450f9c22723ae430e3af3211d
  title_hash = [0u8; 32]   (title absent — §4.2.1 sentinel)

Domain separator (10 bytes):
  [0x51, 0x55, 0x42, 0x5F, 0x49, 0x44, 0x5F, 0x56, 0x32, 0x00]

Preimage (108 bytes—current protocol v1):
  domain_separator    ||  // 10 bytes
  0x01                ||  // version
  0x01                ||  // content_type
  0x0000000067748580  ||  // created_at as i64 big-endian (1735689600)
  0x00000000677DC000  ||  // unlock_at as i64 big-endian (1736294400)
  0x0000000000000000  ||  // outcome_at_or_zero (outcome_at absent)
  0x000000000047A596  ||  // drand_round as u64 big-endian (4695446)
  body_hash           ||  // 32 bytes
  title_hash              // 32 bytes (all-zeros sentinel; title absent)

Expected output:
  qub_id = SHA3-256(preimage)
         = 4a84e3dfaec32954949c30073f8e6506
           fd3204c1bb97f9162b81c7587afe412e

कार्यान्वयन इस इनपुट के लिए समान body_hash और qub_id मान उत्पन्न करना MUST। यह test vector पहला unit test होना SHOULD। ऊपर canonical मान reference implementation ने गणना किए और bit-for-bit मेल खाना MUST। ऐतिहासिक pre-launch prototype layouts (पहले दो पर कोई live qubs निर्भर नहीं थे) ने outcome_at से पहले 92 bytes (3d9fc2390eab043d38a1669ed3b71be76f9eefe872b9569ab1aaa027b88392b0) और outcome_at_or_zero जोड़ने के बाद 100 bytes (b0d032898ad629795150fdcb3f84e518f59ed05b7a2a82bc24ebdb87f52144ed) उपयोग किए। वर्तमान 108-byte layout ने फिर drand_round और QUB_ID_V2 domain separator जोड़े। एक प्रारंभिक 108-byte vector ने पूर्ववर्ती ceil round mapping (drand_round = 4695445) उपयोग की और 3a9fcb31b750d985c262fada6d4f777fd6a28be831d941d85c131f5a4bbaf8a4 बनाया—उस round input के लिए अभी भी वैध qub_id, जबकि ऊपर का उदाहरण §4.3 current-round mapping का अनुसरण करता है।

14.2 Unlock-Round मानचित्रण

Input:
  unlock_at           = 1735689600
  chain_genesis_time  = 1595431050
  chain_period_seconds = 30

Calculation:
  (1735689600 - 1595431050) / 30 = 4675285.0
  floor(4675285.0) + 1 = 4675286

drand_round = 4675286

Round 4675286 1595431050 + (4675286 - 1) * 30 = 1735689600 पर प्रकाशित होता है—ठीक unlock_at पर, उससे पहले कभी नहीं। (पूर्ववर्ती pre-release ceil mapping ने 4675285 दिया, जो 1735689570 पर—30 सेकंड पहले—प्रकाशित हुआ; verifiers §4.3 के अनुसार उस पूर्ववर्ती round को स्वीकार करते हैं।)

14.3 कैनोनिकल CBOR राउंड-ट्रिप

कार्यान्वयन सत्यापित करना MUST कि सभी मान्य इनपुट्स के लिए serialize(parse(serialize(qub))) == serialize(qub)। यह एक गुण परीक्षण है, एकल सदिश नहीं।

14.4 PactTerms CBOR (content_type 0x03)

Input:
  pact_version = 1
  title        = "Scooter deposit"
  terms        = [
    { key: "Item",    value: "Honda Metropolitan scooter" },
    { key: "Price",   value: "$100" },
    { key: "Deposit", value: "$10" }
  ]
  party_a      = { label: "Alice" }
  party_b      = { label: "Bob", contact: "bob@example.com" }
  notes        = absent

Canonical CBOR key order (PactTerms):
  "notes"(6) < "terms"(6) < "title"(6) < "party_a"(8) < "party_b"(8) < "pact_version"(13)

Canonical CBOR key order (PactTerm):
  "key"(4) < "value"(6)

Canonical CBOR key order (PartyIdentifier):
  "label"(6) < "contact"(8)

कैनोनिकल CBOR बाइट्स और SHA3-256 body_hash संदर्भ कार्यान्वयन द्वारा गणना किए जाते हैं। कार्यान्वयन इस इनपुट के लिए बाइट-समान CBOR उत्पन्न करना MUST।

कार्यान्वयन यह भी सत्यापित करना MUST कि सभी मान्य PactTerms इनपुट्स के लिए serialize(parse(serialize(pact))) == serialize(pact) (गुण परीक्षण)।

14.5 बाहरी आवरण क्रॉस-भाषा सदिश

बाहरी आवरण (§13) का crates/qub-core/tests/vectors/wrapper_v1.json पर एक अलग कैनोनिकल फ़िक्स्चर है। प्रत्येक मामला अपारदर्शी हेक्स इनपुट्स के रूप में एक (key, nonce, qub_id, sealed_cbor) टपल को स्थिर करता है और एक विशिष्ट expected_wrapper_hex आउटपुट पर ज़ोर देता है। दोनों संदर्भ कार्यान्वयन समान JSON फ़ाइल का उपभोग करते हैं:

• Rust: crates/qub-core/tests/wrapper_vectors.rs (cargo test -p qub-core --test wrapper_vectors)।
• TypeScript: workers/api/src/crypto/__tests__/wrapper.test.ts (npm test)।

फ़िक्स्चर वर्तमान में तीन निम्न-स्तरीय wrapper मामलों को पिन करता है। वे §13.8 डिलीवरी-आकार invariant से स्वतंत्र रूप से नियतात्मक OuterWrapper एन्कोडिंग और AEAD interoperability जाँचते हैं; विशेष रूप से, ऐतिहासिक नाम basic-text-public और उसका आंतरिक visibility = 0x01 परिणामी रैप किए गए बाइट्स को अनुरूप सार्वजनिक डिलीवरी नहीं बनाते। निर्माता को सार्वजनिक आंतरिक बाइट्स बिना रैप किए संग्रहीत करने और केवल निजी (0x00) आंतरिक बाइट्स को रैप करने की आवश्यकता अब भी है।

कार्यान्वयन रिकॉर्ड किए गए इनपुट्स के लिए बाइट-समान expected_wrapper_hex उत्पन्न करना MUST। फ़िक्स्चर का पुनर्जनन QUB_REGEN_VECTORS=1 cargo test -p qub-core --test wrapper_vectors की आवश्यकता है और जानबूझकर प्रारूप परिवर्तनों के लिए आरक्षित है।

15. क्रिप्टो प्रोफ़ाइल शासन (भविष्य)

यह अनुभाग v1 के लिए सूचनात्मक है और तब मानक बनता है जब पहली बार qub के किसी क्रिप्टोग्राफ़िक आदिम में दूसरा एल्गोरिथम प्रवेश करता है।

15.1 वर्तमान मुद्रा

प्रोटोकॉल v1 प्रति आदिम ठीक एक एल्गोरिथम बांधता है:

• हस्ताक्षर: ML-DSA-65 (sig_alg = 0x01; 1952-बाइट सार्वजनिक कुंजी, 3309-बाइट हस्ताक्षर) और अहस्ताक्षरित (sig_alg = 0x00)। Codebase 0x02 को Ed25519 के लिए आरक्षित करता है, लेकिन protocol v1 इसे सक्रिय नहीं करता; v1 verifier को {0x00, 0x01} के बाहर हर sig_alg अस्वीकार करना MUST।
• टाइमलॉक: केवल drand quicknet — चेन हैश, सार्वजनिक कुंजी, जेनेसिस समय और अवधि स्थिर नेटवर्क पैरामीटर हैं जो संदर्भ DrandTimelockProvider::quicknet() (crates/qub-core/src/tlock.rs) और config/drand-endpoints.json द्वारा वहन किए जाते हैं।
• बाहरी आवरण: केवल AES-256-GCM v1 (§13)।

सत्यापनकर्ता वर्तमान में हर सक्रिय primitive के लिए कुंजी और हस्ताक्षर लंबाइयाँ hardcode करते हैं। sig_alg और wrapper-version bytes स्पष्ट selectors हैं, लेकिन v1 कोई in-band negotiation नहीं करता और केवल ऊपर के सक्रिय मान स्वीकार करता है।

15.2 अभिप्रेत आकार

जब एक दूसरा एल्गोरिथम प्रोटोकॉल में प्रवेश करता है, तो सत्यापनकर्ता को एक नामित CryptoProfile (उदा. ExqubV1) के लिए कॉन्फ़िगर किया जाएगा जो प्रति आदिम अनुमत मानों के सटीक सेट को सूचीबद्ध करता है — sig_algs, drand चेन, आवरण संस्करण, सामग्री प्रकार। प्रोफ़ाइल सत्यापन समय पर तय की जाती है, कभी इन-बैंड बातचीत नहीं की जाती। सक्रिय प्रोफ़ाइल के बाहर का कोई भी मान अस्वीकार कर दिया जाता है।

यह सुनिश्चित करता है कि ML-DSA-87 जोड़ना या Ed25519 सक्रिय करना मौजूदा सत्यापनकर्ता कॉन्फ़िगरेशन को पीछे की ओर कमज़ोर नहीं कर सकता: एक v1 सत्यापनकर्ता एक v2 प्रोफ़ाइल प्रकाशित होने के बाद भी v1 सत्यापनकर्ता ही रहता है।

15.3 ट्रिगर शर्तें

§15 को मानक स्थिति में पदोन्नत करें जब निम्नलिखित में से कोई प्रस्तावित हो:

• एक दूसरा sig_alg बाइट (Ed25519 सक्रियण, ML-DSA-87, या §9 रजिस्ट्री में कोई नई प्रविष्टि)।
• उत्पादन उपयोग में एक दूसरी drand चेन।
• एक दूसरा बाहरी-आवरण संस्करण।
• पारदर्शिता-लॉग trust root—LogProfile.anchor_owner address या pinned receipt-key public key (§16.6)—का rotation। LogProfile एक governed primitive के रूप में §15.2 profile surface से जुड़ता है: rotation एक verifier update में भेजा गया signed LogProfile bump है (planned rotations outgoing → incoming cross-sign करते हैं; compromise-driven rotations नहीं कर सकते और interim damage सीमित करने के लिए इस bump तथा prev-anchor fork check पर निर्भर करते हैं)। पारदर्शिता-लॉग version spaces (LOG_VERSION, ANCHOR_FORMAT) independent siblings के रूप में विकसित होते हैं, ठीक वैसे ही जैसे §12.5 wrapper version protocol version से स्वतंत्र है।

तब तक §15 एक प्लेसहोल्डर है जो माइग्रेशन आकार को स्थिर करता है ताकि भविष्य के PRs बातचीत सतह को नए सिरे से पुनः-निर्धारित करने के बजाय एक ज्ञात लक्ष्य के विरुद्ध उतरें।

16। पारदर्शिता लॉग और स्थायित्व स्तर (कार्यान्वित - समीक्षा पूर्ण)

स्थिति. यह खंड कार्यान्वित (W5/UP-B1, चरण 1-8) है, जिसमें निर्माता और विश्वास-जड़ का दायरा यहां बताया गया है। वायर प्रारूप, हैशिंग और सत्यापनकर्ता पथ लाइव हैं: कोर मर्कल + कैनोनिकल-सीबीओआर प्रकार (qub-core), टाइपस्क्रिप्ट मिरर + एएनएस-104 बंडलर (workers/api/src/crypto/), सिंगल-राइटर LogDO + कोऑर्डिनेट-कीड आर2 नोड स्टोर, /upload लॉग-एपेंड प्रयास, दैनिक एंकर + बंडलर-ड्रेन क्रॉन, GET /api/v1/qub/:tx_id/proof (समावेशन) और GET /api/v1/log/consistency (आरएफसी 9162) प्रूफ एंडपॉइंट, .qub बंडल में टाइप किया गया समावेशन प्रमाण (§17.5), देशी ANS-104 एंकर सत्यापनकर्ता (tools/qub-verify), और दोहरी स्व-प्रकाशित-हेड्स हुक (§16.6)। एक सफल /upload हमेशा R2-टिकाऊ होता है, लेकिन केवल तभी लॉग-कवर होता है जब LOG_DO कॉन्फ़िगर किया जाता है और इनलाइन परिशिष्ट सफल होता है; तभी इसकी प्रतिक्रिया log_seq, receipt और anchor_status ले जाती है। यदि RECEIPT_SK अनुपस्थित या अमान्य है, तो उस रसीद का sig_b64url खाली है और कोई गैर-अस्वीकृति प्रदान नहीं करता है। वर्तमान /seal और पैक्ट प्रकाशन पथ अलग-अलग Arweave लेनदेन को शेड्यूल करते हैं लेकिन लॉग लीफ नहीं जोड़ते हैं। कोई भी कोड वर्तमान में एक परिशिष्ट विफलता के बाद /upload टिप्पणी के प्रस्तावित बाद के सामंजस्य को निष्पादित नहीं करता है। W5 बाहरी समीक्षा पूरी हो गई है: §16.15 डिज़ाइन निर्णयों और लॉन्च बाधाओं को रिकॉर्ड करता है, लेकिन वे बाधाएं अभी बताए गए निर्माता कवरेज का विस्तार नहीं करती हैं। तीन ट्रस्ट/परिनियोजन आइटम गेट रहते हैं: (ए) समर्पित एंकर वॉलेट (ANCHOR_JWK; LogProfile.anchor_owner अभी भी [0xAB; 32] प्लेसहोल्डर है); (बी) रसीद हस्ताक्षर कुंजी और मिलान सार्वजनिक-कुंजी पिन (RECEIPT_SK वैकल्पिक है और LogProfile.receipt_pubkey वर्तमान में खाली है); और (सी) स्व-प्रकाशित-हेड GitHub रिपॉजिटरी + टोकन (§16.6)। जब तक एंकर/प्रोफाइल पिन का प्रावधान नहीं किया जाता है, तब तक एक स्टैंडअलोन सत्यापनकर्ता पूरी तरह से एंकर, पिन किए गए सत्यापन का दावा करने के बजाय ईमानदारी से प्रमाण स्थिति की रिपोर्ट करता है। डिज़ाइन सख्ती से योगात्मक है और SealedQub/QubEnvelope तार प्रारूप में कोई बदलाव नहीं है।

16.1 तर्क और स्थायित्व स्तर

वर्तमान प्रकाशन पथ Arweave पुष्टिकरण से पावती को अलग करते हैं: वे एक व्यक्तिगत लेनदेन प्राप्त करते हैं और हस्ताक्षर करते हैं, R2 में आर्टिफैक्ट और सटीक सबमिशन स्थिति को बनाए रखते हैं, फिर अतुल्यकालिक रूप से पोस्ट करते हैं। पारदर्शिता लॉग सामान्य /upload अनुरोधों के सबसेट के लिए एक स्वतंत्र रूप से लंगर डाले गए ऑर्डरिंग परत जोड़ता है जिसका LogDO परिशिष्ट सफल होता है:

ये स्तर विभिन्न साक्ष्य और टिकाऊपन गुणों का विवरण देते हैं, वर्तमान व्यावसायिक योजना नहीं। वर्तमान कोड अब भी प्रत्येक स्वीकृत प्रकाशन के लिए एक व्यक्तिगत Arweave लेनदेन निर्धारित करता है; यह केवल T3 को भुगतान किए गए अपसेल के रूप में उजागर नहीं करता। API-कुंजी / खाता कोटा सीमाएँ अलग आवेदन नियंत्रण में रहती हैं।

टिकाऊपन ईमानदारी। T1 लेखन समकालिक है, इसलिए सफल प्रतिक्रिया एप्लिकेशन-स्तरीय टिकाऊपन स्थापित करती है बिना Arweave गेटवे की प्रतीक्षा किए। यह स्वयं स्वतंत्र टाइमस्टैम्प स्थापित नहीं करता। एक पुष्ट व्यक्तिगत लेनदेन अपने ब्लॉक-समय ऊपरी सीमा प्रदान करता है। यदि प्रतिक्रिया पूरी T2 रसीद जोड़ी लेकर आती है, तो अगला पुष्ट एंकर नीचे वर्णित लॉग प्रमाण प्रदान कर सकता है। यदि जोड़ी अनुपस्थित है, तो कोई सतह यह नहीं संकेत दे सकती कि यह क्यूब पहले से पारदर्शिता लॉग में है। एंकर और प्रकाशन विलंबता का कोई प्रोटोकॉल-स्तरीय संख्यात्मक SLA नहीं है।

16.2 लॉगलीफ संरचना (दो प्रतिबद्ध रूप)

एक लॉग एंट्री एक LogLeaf है, जिसे §3.1 प्रोफ़ाइल (निश्चित-लंबाई, कोई टैग नहीं, कोई फ्लोट्स नहीं, सबसे छोटी-फॉर्म की पूर्णांक, NFC टेक्स्ट, गैर-मौजूद विकल्प फ़ील्ड्स को छोड़ दिया गया, कुंजियाँ एन्कोडेड-बाइट लंबाई के आरोही क्रम और फिर बाइट वाइज क्रम में) के अंतर्गत हाथ से लिखी गई कैनॉनिकल CBOR के रूप में एन्कोड किया गया है। §3.1 parse → re-encode → compare कैनॉनिकल गार्ड हैशिंग से पहले एन्कोड पाथ पर लागू किया जाता है (केवल डिकोड पर नहीं), इसलिए दो इम्प्लीमेंटेशन पूर्णांक-चौड़ाई या कुंजी-क्रम के अंतर के माध्यम से लीफ बाइट्स पर असहमत नहीं हो सकते। सभी पूर्णांक u8 / u64 / i64 हैं; सभी डाइजेस्ट 32-बाइट बाइट स्ट्रिंग्स हैं (bstr[32])। एक संग्रहीत Arweave ट्रांज़ैक्शन आइडी एक कच्चा 32-बाइट SHA-256 डाइजेस्ट है जिसे bstr[32] के रूप में ले जाया जाता है, कभी भी बेस64url टेक्स्ट स्ट्रिंग नहीं (मिली हुई §3.3 से)।

लीफ के दो आकार हैं जो kind बाइट द्वारा चुने जाते हैं, क्योंकि सामान्य अपलोड पाथ बाइट-ब्लाइंड है: POST /api/v1/upload जानबूझकर दोनों स्वीकृत पेलोड आकारों को अस्पष्ट मानता है और केवल अविश्वसनीय क्लाइंट दावों के रूप में qub_id और unlock_at प्राप्त करता है। डिफ़ॉल्ट निजी पाथ पर, body_hash, drand_round, created_at, और drand_chain_version अतिरिक्त रूप से §13 बाहरी रैपर के अंदर छुपी होती हैं, जिसका कुंजी वर्कर कभी नहीं रखता। टाइप सिस्टम एक प्रमाणित आकार भी परिभाषित करता है जो एक निर्माता के लिए body_hash / drand_round स्वयं व्युत्पन्न करता है। वर्तमान /seal रूट में ये मान होते हैं लेकिन LogDO को कॉल नहीं करता, इसलिए उत्पादन वर्तमान में केवल सफल सामान्य-अपलोड एप्पेंड से दावा किए गए (0x02) लीफ्स ही जारी करता है। यह विभाजन हर प्रतिबद्ध मूल्य को ईमानदार बनाए रखता है बिना इस भ्रम के कि प्रमाणित निर्माता वायर्ड है:

एक kind=0x02 पत्ता जानबूझकर न तो body_hash करता है और न ही drand_round: यह सामग्री-पते chash पर एक अपारदर्शी सिफरटेक्स्ट की प्रतिबद्धता और आदेश को प्रमाणित करता है, qub_id और unlock_at* का दावा करता है - न कि इसका सादा पाठ या गोल। एक दावा किए गए क्यूब के लिए सादा पाठ/गोल पैर मौजूदा §11 .qub-बंडल सत्यापन से आते हैं, न कि लॉग (§16.11) से। drand_chain_version पत्ती में नहीं है (यह डिफ़ॉल्ट पथ पर आवरण के अंदर है); चेन ग्रैन्युलैरिटी एंकर (§16.7) पर रहती है। एनकोडर अनुशासन: एक ऑल-जीरो ref या chash को अस्वीकार करें, और गैर-सकारात्मक unlock_at/received_at को अस्वीकार करें, जो cbor.rs में outcome_at > 0 प्रहरी गार्ड को प्रतिबिंबित करता है।

16.2.1 निजी-क्यूब अंधा करना

लॉग को गणना दैवज्ञ नहीं बनना चाहिए जिसे रोकने के लिए §13 बाहरी आवरण मौजूद है (§13.1)। एक निजी (लपेटा हुआ) क्यूब के लिए asserted पत्ती **अंधा ** पहचानकर्ता SHA3-256(qub_id ‖ log_blind_secret) करता है, जहां log_blind_secret एक सर्वर-आयोजित रहस्य है, और body_hash को छोड़ देता है। कोई तीसरा पक्ष इस तरह के पत्ते को किसी विशिष्ट qub_id से नहीं बांध सकता है; क्यूबी का धारक, जिसके पास डिलीवरी यूआरएल है और इसलिए qub_id, अपने स्वयं के समावेशन की पुष्टि करने के लिए अंधे की पुनर्गणना कर सकता है। एक सार्वजनिक क्यूब (पहले से ही गणनायोग्य, पहले से ही Visibility: public Arweave टैग प्रति §13.8) कच्चे qub_id को प्रतिबद्ध करता है। यह एक ऐसी जगह है जहां स्टैंडअलोन सत्यापन जानबूझकर लोड-असर वाली गोपनीयता अपरिवर्तनीय को जन्म देती है; निजी क्यूब्स के लिए स्टैंडअलोन टाई chash (§16.9) है।

**log_blind_secret हिरासत (हल किया गया - §16.15 Q4)। ** अंधा पत्ती अनलिंकबिलिटी की रक्षा करता है, न कि सादे पाठ की गोपनीयता (§13 आवरण इसे स्वतंत्र रूप से रखता है)। एक log_blind_secret समझौते पर, किसी भी qub_id के लिए विरोधी पहले से ही रखता है या पुनर्निर्माण कर सकता है (प्रत्येक क्यूब जिसका बंडल/यूआरएल उसके पास है, साथ ही कोई कम-एन्ट्रापी या सार्वजनिक qub_id) यह एक हैश में पत्ती ref की पुनर्गणना करता है और इसे जोड़ता है - यह एक ज्ञात आबादी का सीधा संबंध है, न कि किसी अज्ञात स्थान पर एक क्रूर-बल। log_blind_secret को अन्य सर्वर रहस्यों के समान हिरासत स्तर में एक सहसंबंध/सिबिल-ग्रेड रहस्य के रूप में वर्गीकृत करें, और केवल आगे की ओर घुमाएं (एक रोटेशन भविष्य के पत्तों को फिर से अंधा कर देता है; यह पहले से ही लंगर डाले गए लोगों को पूर्वव्यापी रूप से अनलिंक नहीं कर सकता है)।

16.3 लीफ और नोड हैशिंग

RFC 6962 §2.1 SHA-256 के साथ डोमेन-अलग हैशिंग को SHA3-256 द्वारा प्रतिस्थापित किया गया:

leaf_hash      = SHA3-256(0x00 || canonical_cbor(LogLeaf))
node_hash(l,r) = SHA3-256(0x01 || l || r)
empty tree     = SHA3-256("")          // defined but never anchored

डोमेन उपसर्ग बाइट्स 0x02 (प्रवेश श्रृंखला, §16.4) और 0x03 (एसटीएच हैश, §16.6) इनसे आरक्षित और असंबद्ध हैं। वे सिंगल बाइट्स हैं और इसलिए मौजूदा 10-बाइट ASCII डोमेन विभाजक (QUB_ID_V2, आदि) से नहीं टकरा सकते हैं। पेड़ आरएफसी 6962 बाएं-पूर्ण असंतुलित पेड़ है (प्रत्येक आंतरिक विभाजन दो की सबसे बड़ी शक्ति पर सख्ती से सबट्री पत्ती की गिनती से कम है), जो समावेशन और स्थिरता प्रमाण को एक ऑडिट-पथ एल्गोरिथ्म साझा करने देता है। संदर्भ युक्ति में स्पष्ट बाएँ/दाएँ व्युत्पत्ति छद्म कोड होता है और एक गैर-पावर-ऑफ-टू (5-पत्ती) परीक्षण वेक्टर पिन करता है, इसलिए दाएं-किनारे का प्रचार मामला - जो 4-पत्ती वेक्टर छुपाता है - का प्रयोग किया जाता है।

16.4 हैश चेनिंग (आंतरिक)

LogDO केवल क्रैश-स्थिरता के लिए एक आंतरिक प्रविष्टि श्रृंखला बनाए रखता है। यह कभी प्रकाशित नहीं होता है और कभी भी सत्यापनकर्ता-सामना नहीं करता है:

entry_chain[seq] = SHA3-256(0x02 || entry_chain[seq-1] || leaf_hash[seq])
entry_chain[-1]  = SHA3-256("QUB_TLOG_GENESIS_V1")

प्रकाशित परिशिष्ट-केवल प्राधिकरण **संचयी मर्कल रूट + इसका लंगर ** (§16.5-16.6) है, कभी भी कच्चा क्रम नहीं जिसमें ऑपरेटर पत्तियों की सेवा करता है: श्रृंखला किसी भी आदेश के लिए पुन: गणना करती है, इसलिए केवल लंगर डाले गए रूट पिन विहित स्थिति।

16.5 संचयी मर्कल ट्री और बैचिंग

seq क्रम में सभी पत्तियों पर **एक लगातार बढ़ने वाला आरएफसी 6962 पेड़ ** है - अलग-अलग प्रति-बैच पेड़ नहीं। (एक कैरी-लीफ-जंजीर प्रति-बैच निर्माण को अस्वीकार कर दिया गया था: यह एक सच्चा उपसर्ग संबंध नहीं है, इसलिए इसके "स्थिरता प्रमाण" अनुचित हैं। संचयी पेड़ वास्तविक आरएफसी 9162 स्थिरता प्रमाण देता है और एक हालिया एंकर को किसी भी पुराने क्यूब के लिए समावेशन साबित करने देता है।

LogDO टिकाऊ वस्तु एकल लेखक (blockConcurrencyWhile, मिररिंग QuotaDO/EntitlementDO) है - एक साझा लॉग में जोड़ना साझा स्थिति पर पढ़ना-संशोधित-लिखना है और इसलिए एक DO से गुजरना चाहिए, कभी भी KV नहीं। यह पेड़ के दाहिने किनारे की सीमा (O(log n) हैश) को कैश करता है, इसलिए एक बैच को बंद करना O(batch) है। एक बैच एक साथ लंगर डाले हुए पत्तियों का सेट है; इसके कार्यान्वित ट्रिगर कम से कम LOG_BATCH_MAX_LEAVES (डिफ़ॉल्ट 4096) का tree_size अग्रिम हैं, एंकर ताल तक पहुंचने की आयु, या एक स्पष्ट प्रशासनिक/क्रॉन बल-बंद। root_i पत्तियों 0 .. tree_size_i पर संचयी मर्कल ट्री हैश है।

16.6 Arweave एंकर के माध्यम से हस्ताक्षरित ट्री हेड

Arweave एंकर लेनदेन **** हस्ताक्षरित ट्री हेड है और बदलता है एक ऑपरेटर हस्ताक्षर ट्री हेड के लिए ही: दैनिक एंकर को किसी क्यूब कुंजी की आवश्यकता नहीं होती है क्योंकि Arweave tx owner हस्ताक्षर है। खाई थीसिस में है - अपरिवर्तनीय सब्सट्रेट, क्यूब-आयोजित रहस्य नहीं, लंगर वाली जड़ के लिए लोड-असर है।

लॉग डिज़ाइन एक गर्म सफल-जोड़ रसीद कुंजी (§16.10) के लिए कहता है, जिसे LogProfile में पिन किया जाता है और anchor_owner द्वारा क्रॉस-हस्ताक्षरित किया जाता है। वर्तमान कार्यान्वयन ने उस ट्रस्ट-रूट प्रावधान को पूरा नहीं किया है: RECEIPT_SK वैकल्पिक है, एक अनुपस्थित/अमान्य कुंजी sig_b64url: "" उत्पन्न करती है, और संकलित LogProfile.receipt_pubkey खाली है। ऐसी रसीद संलग्न पत्ती का वर्णन कर सकती है लेकिन नहीं एक गैर-अस्वीकृत हस्ताक्षरित रसीद है। मजबूत डिज़ाइन दावा केवल तभी लागू होता है जब एक सत्यापनकर्ता रिलीज़ मेल खाने वाली सार्वजनिक कुंजी को पिन करता है और एंकर स्वामी इसे क्रॉस-साइन करता है। पूर्ण रसीद टपल के बिना एक प्रकाशन प्रतिक्रिया कोई लॉग-स्वीकृति दावा नहीं करती है; एक खाली हस्ताक्षर के साथ एक परिशिष्ट-स्थिति का दावा करता है लेकिन कोई हस्ताक्षर-सत्यापन दावा नहीं करता है।

SignedTreeHead विहित सीबीओआर (एन्कोडेड लंबाई द्वारा कुंजियाँ) है: size:u64, root:bstr[32], batch:u64, prev:bstr[32] (sth_hash से पहले; उत्पत्ति = 32 शून्य बाइट्स), log_id:bstr[32], first_seq:u64, anchored_at:i64। इसका हैश sth_hash = SHA3-256(0x03 || canonical_cbor(SignedTreeHead)) है।

**पिन किया गया ट्रस्ट रूट। log_id = SHA3-256("QUB_TLOG_V1" || anchor_owner_address) एक अनुरूप सत्यापनकर्ता को anchor_tx.owner == LogProfile.anchor_owner की आवश्यकता होनी चाहिए, जहां anchor_owner (और रसीद-कुंजी सार्वजनिक कुंजी) को LogProfile के रूप में qub_core में बेक किया जाता है - पहले से ही DrandTimelockProvider::quicknet() में क्विकनेट स्थिरांक के साथ - और सत्यापनकर्ता बाइनरी के साथ वितरित किया जाता है। सत्यापनकर्ता को प्रतिक्रिया के प्रवेश द्वार पर भरोसा करने के बजाय Arweave tx **डेटा → tx_id स्थानीय रूप से बाध्यकारी ** को भी सत्यापित करना /raw/ चाहिए। यह दुष्ट-वॉलेट इक्विवोकेशन छेद को बंद कर देता है: "Arweave पर लंगर डाले हुए" तब तक अर्थहीन है जब तक कि सत्यापनकर्ता जो वॉलेट पिन न कर दे।

**रोटेशन एक §15 शासन एक्सटेंशन है, पुन: उपयोग नहीं (हल किया गया - §16.15 Q3)। §15.2 की प्रोफ़ाइल सतह वर्तमान में केवल sig_algs/drand चेन/रैपर संस्करण/सामग्री प्रकारों की गणना करती है, और §15.3 के ट्रिगर इनमें से कोई भी नहीं सूचीबद्ध करते हैं - LogProfile/anchor_owner अभी तक §15 की सतह में नहीं है। इसलिए रोटेशन गवर्नेंस को निर्मित होना चाहिए: LogProfile ट्रिगर जोड़ने के लिए §15.3 को (नीचे) बढ़ाया गया है, और एक रोटेशन एक सत्यापनकर्ता अपडेट में भेजा गया एक हस्ताक्षरित LogProfile बम्प है। एक नियोजित रोटेशन एक आउटगोइंग → इनकमिंग क्रॉस-सिग्नेचर करता है; एक समझौता-संचालित रोटेशन नहीं हो सकता है (आउटगोइंग कुंजी अविश्वसनीय/अनुपलब्ध है) और §15-शासित बम्प पर वापस आ जाती है, जिसमें पिछला-एंकर फोर्क चेक (नीचे) अंतरिम में बाउंडिंग क्षति होती है।

**इक्विवोकेशन विंडो (प्रथम श्रेणी ट्रस्ट पैरामीटर)। ** एक पत्ता केवल तभी समतुल्य-प्रतिरोधी होता है जब उसका कवरिंग एंकर Arweave-पुष्टि की जाती है। खिड़की received_at → anchor confirmation है (ताल + Arweave अंतिमता, बिना किसी प्रोटोकॉल विलंबता गारंटी के)। ट्रस्ट-रूट प्रावधान से पहले, वर्तमान कार्यान्वयन क्यूब की परिचालन अखंडता के साथ-साथ जो भी अहस्ताक्षरित परिशिष्ट मेटाडेटा मौजूद है, उसकी आपूर्ति करता है; यह नियोजित गैर-अस्वीकृति गारंटी की आपूर्ति नहीं करता है। तीन जवाबदेही कलाकृतियां पूर्ण डिजाइन को परिभाषित करती हैं (गवाह मॉडल §16.15 Q2 का संकल्प है):

1. सील रसीद (प्रावधान-निर्भर) — वह SCT समकक्ष जिसे अपलोड की लॉग_APPEND सफल होने पर लौटाया जाता है (§16.10)। यह केवल तब गैर-इनकार योग्य बनती है जब sig_b64url खाली न हो और मिलान करने वाली सार्वजनिक कुंजी/एंकर-मालिक का संबंध वेरीफायर में पिन किया गया हो। वर्तमान में खाली उत्पादन प्रोफाइल पिन उस निर्णय का समर्थन नहीं कर सकती। यह नियंत्रण छोड़ी गई रसीद टपल या बिना हस्ताक्षर वाली रसीद पर लागू नहीं होता।

2. प्रकाशित मॉनिटर कार्यप्रणाली + पूर्व-चेन वॉक — एंकर prev चेन को हेड→जेनेसिस तक वॉक किया जाता है; एक फोर्क (एक size पर दो एंकर अलग root के साथ, या एक टूटा हुआ prev) कुप्रवृत्ति का प्रकाशित प्रमाण है। अपवाद पता लगाना एक घोषित संचालन प्रतिबद्धता है, न कि मौन अनुमान।

3. डुअल स्व-प्रकाशित हेड्स — प्रत्येक नया हेड {sth_hash, tree_size} समर्पित qub-संपन्न सार्वजनिक, केवल-एपेंड GitHub रिपॉजिटरी में पोस्ट किया जाता है (लोड-बेयरिंग टेम्पर-एविडेंट स्व-प्रकाशन चरण), केवल सामाजिक पोस्ट को सर्वोत्तम प्रयास पुष्टि के रूप में रखा गया है। एक असफल पोस्टिंग को अवश्य पेज होना चाहिए (मौन रूप से असफल नहीं होना चाहिए)। अंकर क्रोन पर workers/api/src/utils/heads-publish.ts के रूप में publishHead हुक के रूप में लागू किया गया (स्टेज 8): एक PUT सामग्री API के लिए बिना sha के केवल-एपेंड है (एक 422 का मतलब है कि हेड पहले ही प्रकाशित है, कभी ओवरराइट नहीं); PUBLISH_HEAD_GITHUB_{TOKEN,OWNER,REPO} पर ऑप्ट-इन / डिप्लॉय-गेटेड और रिपॉजिटरी प्रावधान तक निष्क्रिय। एक हार्ड GitHub विफलता health_alert चैनल के माध्यम से पेज करती है और एक टिकाऊ फेल मीट्रिक को बढ़ाती है (m:tlog_publish_head_fail); Arweave एंकर खुद प्रकाशित विफलता पर कभी रोलबैक नहीं करता। "मौन रूप से न असफल होने" की गारंटी उस टिकाऊ मीट्रिक द्वारा दी जाती है — जिसे ऑप्स को डैशबोर्ड-चेतावनी देना आवश्यक है — भले ही सर्वोत्तम प्रयास ईमेल पेज नहीं पहुंचाया जा सके। "एंकर-ऑन-अडवांस" (क्रोन केवल तब प्रकाशित करता है जब आकार आगे बढ़ता है) से दो ईमानदार सीमाएँ आती हैं: एक अस्थायी GitHub विफलता प्रकाशित-हेड्स अनुक्रम में उस आकार के लिए गैप छोड़ देती है — सीमित, मौन नहीं (यह पेज करता है), और क्योंकि प्रत्येक हेड एक सुपरसेट ट्री को कमिट करता है, एक §16.9 संगतता प्रमाण उस गैप को पाटता है; महत्वपूर्ण रूप से, वह संगतता प्रमाण प्राधिकृत Arweave-एंकर किए गए ट्री से गणना की जाती है, न कि GitHub सतह से, इसलिए GitHub गैप कभी सत्यापन क्षमता को कमजोर नहीं करता। एक कैच-अप बैकफिल जो प्रकाशित-हेड्स गैप को भरता है, एक स्थगित सुधार है।

ईमानदारी बाध्य (बाध्यकारी बाधा). क्योंकि क्यूब दोनों नियोजित पोस्टिंग सतहों को नियंत्रित करता है, यह स्व-प्रकाशित है, स्वतंत्र रूप से नहीं देखा गया है। कोई भी उत्पाद, विपणन, या कानूनी सतह यह दावा नहीं कर सकती है कि लॉग "स्वतंत्र रूप से गवाही" है। रसीद/प्रोफ़ाइल/हेड गेट्स का प्रावधान करने के बाद, अनुमत दावा यह है कि इक्विवोकेशन का पता लगाया जा सकता है और एक सफलतापूर्वक हस्ताक्षरित परिशिष्ट एक गैर-अस्वीकृत रसीद छोड़ देता है। इससे पहले, वह दावा अनुपलब्ध है। एक सच्चे स्वतंत्र तृतीय-पक्ष गवाह को भविष्य के §15 शासन टक्कर के लिए स्थगित कर दिया जाता है।

received_at ऑपरेटर-दावा किया जाता है और कोई दावा इस पर निर्भर नहीं हो सकता है - यह कभी भी किसी भी उत्पाद / कानूनी / एपीआई / प्रूफ-रेंडरिंग सतह पर सबूत या विवाद पुष्टि के रूप में सामने नहीं आता है। Arweave एंकर ब्लॉक समय T एकमात्र भरोसेमंद टाइमस्टैम्प ("लॉग बाय" पर एक ऊपरी सीमा) है। received_at पर किसी भी मॉनिटर विवेक की जांच T के खिलाफ तुलना करनी चाहिए, न कि ऑपरेटर-नियंत्रित anchored_at एसटीएच फ़ील्ड के खिलाफ; इस तरह की जांच केवल एक ईमानदार ऑपरेटर की घड़ी बग के खिलाफ एक गार्ड है, नहीं एक दुर्भावनापूर्ण ऑपरेटर (§16.15 Q5) के खिलाफ जवाबदेही नियंत्रण।

16.7 एंकर लेनदेन प्रारूप और ताल

AnchorBundle विहित-सीबीओआर अरवीव लेनदेन निकाय है, जिसे §16.8 बंडलर के माध्यम से लिखा गया है: ver:u8, sth:bstr (विहित SignedTreeHead बाइट्स), prev_anchor:bstr (पूर्व एंकर tx आईडी कच्चे बाइट्स; उत्पत्ति पर छोड़ा गया), chain_hash:tstr (बल में ड्रंड श्रृंखला - क्विकनेट), और बैच का पत्ता-सीबीओआर धारा seq क्रम में इसलिए एंकर स्व-निहित है: एक मॉनिटर शून्य क्यूब निर्भरता के साथ शरीर से root को फिर से प्राप्त करता है। (यदि पत्ती की धारा उच्च मात्रा में बड़ी हो जाती है, तो भविष्य में संशोधन संदर्भ द्वारा केवल एक पत्ती सीमा को प्रतिबद्ध कर सकता है; नोट किया गया है, v1 में नहीं अपनाया गया है।

Arweave टैग जानबूझकर गणना योग्य हैं - लॉग का मतलब पाया जाना है, निजी क्यूब्स के विपरीत: App-Name: qub-tlog, Anchor-Format: 1, Log-Id: <hex>, Batch: <n>, Tree-Size: <n>, Root: <hex>, Prev-Anchor: <tx>, Content-Type: application/cbor। टैग अविश्वसनीय संकेत हैं; सीबीओआर निकाय एकमात्र प्राधिकरण है।

ताल: डिफ़ॉल्ट रूप से दैनिक, वॉल्यूम के साथ पुन: देखा गया (आकार ट्रिगर लोड के तहत प्रभावी ताल को ऑटो-छोटा करता है)। वर्तमान निर्माता पेड-सील फोर्स-एंकर हुक को लागू नहीं करता है। एंकर वॉलेट समर्पित और कम-वेग वाला है, अपलोड वॉलेट से अलग है - यह इसका अपना JWK होना चाहिए (एक अलग कुंजी, अपलोड वॉलेट पर तार्किक भूमिका नहीं) इसलिए एक अपलोड-वॉलेट समझौता एंकर नहीं बना सकता है - एक कठिन प्रति-दिन एंकर-लेनदेन बजट के साथ। हिरासत की मुद्रा स्पष्ट रूप से बताई गई है: एक तंग सर्किट ब्रेकर और कम संतुलन के साथ एक संकीर्ण-दायरे वाली गर्म कुंजी, "ठंडा" नहीं - एक बटुआ जो दैनिक रूप से ऑटो-साइन करता है, ठंडा नहीं हो सकता है, और कल्पना अन्यथा दिखावा नहीं करती है।

16.8 ANS-104 बंडलर

एक इन-हाउस ANS-104 डेटाआइटम एनकोडर और डीप-हैश साइनर, लगभग 300 लाइनें, केवल वेब क्रिप्टो, शून्य एनपीएम निर्भरता (दोनों टर्बो एसडीके npm ci --ignore-scripts आपूर्ति-श्रृंखला गेट को विफल करते हैं)। डेटाआइटम बाइट लेआउट:

signatureType (2, LE) || raw_signature || owner || target(flag+0|32) || anchor(flag+0|32) || num_tags(8, LE) || tags_len(8, LE) || avro_tags || data

हस्ताक्षर Arweave deepHash है - एक पुनरावर्ती SHA-384 डाइजेस्ट (Arweave की तार की आवश्यकता, crypto.subtle.digest("SHA-384")) ["dataitem", "1", sig_type, owner, target, anchor, encoded_tags, data] से अधिक - फिर crypto.subtle के माध्यम से वॉलेट JWK के साथ गहरे हैश पर RSA-PSS; id = base64url(SHA-256(signature))। यहां SHA-384 को Arweave-तार-केवल आदिम के रूप में संगरोध किया गया है, कभी भी क्यूब ट्रस्ट आदिम नहीं है (§15 बाड़ को रिकॉर्ड करता है; क्यूब ट्रस्ट हैशिंग SHA3-256 है)।

ANS-104 कोड पथ आस्थगित फ़ॉलबैक/ड्रेन मशीनरी का कार्य करता है और डेटाआइटम AnchorBundle लिखता है। साधारण प्रकाशन पथ सबसे पहले एक सटीक हस्ताक्षरित Arweave लेनदेन बनाता है और अपने JSON को एक टिकाऊ आउटबॉक्स में रखता है; प्रत्यक्ष पोस्टिंग एक विलंबता अनुकूलन है, और नाली पथ अपने बंडलर फ़ॉलबैक को लागू करने से पहले उसी लेनदेन का पुनः प्रयास करता है। हस्ताक्षर योजना (हल - §16.15 Q8): RSA-PSS (हस्ताक्षर प्रकार 1) मौजूदा Arweave वॉलेट JWK तंत्र का पुन: उपयोग करना (शून्य नई लंबे समय तक रहने वाली कुंजी हिरासत, "एक कम गुप्त" थीसिस की सेवा करना); Ed25519 को §15 PQ-माइग्रेशन पथ पर स्थगित कर दिया गया है।

हाथ से लुढ़का हुआ डीप हैश W5 में सबसे अधिक जोखिम, सबसे कम-प्राकृतिक-कवरेज कोड है, इसलिए इसका गेटिंग गैर-परक्राम्य (§16.15 Q8) है:

1. क्रॉस-भाषा फिक्स्चर tlog_v1.json (रस्ट + TS, §14.5 wrapper_v1.json पैटर्न) डीप-हैश, DataItem बाइट्स + आईडी, लीफ हैश, 5-लीफ रूट + ऑडिट पथ, एक STH हैश, सम्मिलन प्रमाण, और संगति प्रमाण को कवर करता है — दोनों साइन और वेरीफाई दिशाओं में (वेरीफाई दिशा महत्वपूर्ण है क्योंकि §16.6 का लोकल tx → tx_id चेक डीप हैश को हर स्टैंडअलोन वेरिफ़ायर में खींचता है, केवल लेखक में नहीं)।
2. एक बार की इंटरऑप राउंड-ट्रिप एक संदर्भ ANS-104 बंडलर के माध्यम से, जिसे केवल स्टैटिक टेस्ट डेटा के रूप में इस्तेमाल किया जाता है — कभी भी npm रनटाइम डिपेंडेंसी नहीं (Web-Crypto-ओनली / नो-इंस्टॉल-स्क्रिप्ट्स की स्थिति बरकरार रहती है)।
3. डीप-हैश + RSA-PSS पथ को उसी crypto.subtle प्रिमिटिव्स के माध्यम से राउंड-ट्रिप करना आवश्यक है, जिनका उत्पादन में उपयोग होता है, ताकि इन-हाउस एन्कोडर बाइट-संगत हो।
4. एक चल रही पोस्ट-बंडल स्वीकृति मॉनिटरिंग प्रत्येक एंकर / फॉलबैक DataItem की वास्तव में Arweave स्वीकृति प्राप्त करने की पुष्टि करता है, अलार्म + सर्किट ब्रेकर के साथ — क्योंकि डीप हैश Arweave-अनुपलब्धता फॉलबैक कतार के लिए भी कार्य करता है, इसलिए एक मौन रिग्रेशन उस कतार को नेटवर्क-खारिज किए गए आइटम्स से भर देगा उसी आउटेज के दौरान जिसे यह कवर करने के लिए मौजूद है।

16.9 सम्मिलन और संगति प्रमाण

दोनों RFC 9162, SHA3-256 हैं, जिन्हें कैनोनिकल CBOR के रूप में परोसा जाता है।

InclusionProof — GET /api/v1/qub/:tx_id/proof: ver:u8, leaf:bstr (सटीक लीफ CBOR — वेरिफ़ायर स्वयं leaf_hash की गणना करता है और कभी भी प्रदत्त हैश पर भरोसा नहीं करता), index:u64, size:u64, audit:[bstr[32]], root:bstr[32], anchor:{ txid:bstr[32], batch:u64, sth:bstr[32], log_id:bstr[32], block_height?:u64, anchored_at?:i64 }।

ConsistencyProof — GET /api/v1/log/consistency?first=<size_a>&second=<size_b>: ver:u8, first_size:u64, second_size:u64, first_root:bstr[32], second_root:bstr[32], nodes:[bstr[32]], first_anchor, second_anchor। एक स्पष्ट और अस्पष्ट रहित कुंजी सूची, टेस्ट वेक्टर द्वारा पिन की गई।

स्टैंडअलोन वेरीफिकेशन (कोई qub सर्वर नहीं, §11 का विस्तार):

1.  Parse .qub bundle → SealedQub; recompute qub_id (§4.1).
2.  Read leaf.kind.
3a. kind=0x01 (attested):
      assert leaf.ref == qub_id
      assert leaf.body_hash   == SHA3-256(body)
      assert leaf.drand_round == unlock_round(unlock_at)
3b. kind=0x02 (asserted):
      assert leaf.ref == SHA3-256(qub_id || blind)   // holder supplies blind
      OR treat ref as opaque and bind via leaf.chash == SHA3-256(stored_bytes)
4.  Recompute leaf_hash = SHA3-256(0x00 || leaf); fold `audit` per RFC 6962
    using index/size; require derived root == proof.root.
5.  Fetch anchor.txid from any gateway; verify the tx data → tx_id binding
    (do not trust a gateway /raw/ response); REQUIRE anchor_tx.owner ==
    LogProfile.anchor_owner.
6.  Parse AnchorBundle; require committed root == proof.root and size ==
    proof.size; read the Arweave block time T.
7.  Emit the claim scoped by leaf.kind (§16.11).

**प्रूफ-सर्विंग स्टोरेज को समन्वय-कुंजी होना चाहिए (हल किया गया - §16.15 Q7, पूर्व शर्त को अवरुद्ध करना)। ** कोल्ड-लीफ प्रूफ जनरेशन शुद्धता-तटस्थ है केवल अगर R2 ऑडिट सामग्री एक लगातार मर्कल-नोड स्टोर है जो निरपेक्ष वृक्ष समन्वय (level, index) द्वारा कुंजी की जाती है - प्रति-batch नोड डेल्टा नहीं। एक समन्वय-कुंजी वाले स्टोर के साथ, कोई भी (leaf i, size N) ऑडिट पथ O(log N) प्रत्यक्ष R2 GET का एक सेट है जिसमें बैच सीमाओं के पार कोई पुनर्गणना नहीं है; बैच-कुंजी वाले स्टोर के साथ यह नहीं है, जो कि भंडारण-लेआउट अंतर है जो यह रिज़ॉल्यूशन बंद कर देता है। पत्ती के शरीर भी seq द्वारा सामग्री-पता योग्य हैं। एक W5 परीक्षण वेक्टर को बहुत बाद में जड़ के खिलाफ उत्पत्ति-युग की ठंडी पत्ती साबित करनी चाहिए, केवल R2 + Arweave का उपयोग करके LogDO भंडारण मिटा दिया गया , इसलिए §16.13 में पुनर्ग्रहण-सुरक्षा दावा दावा करने के बजाय समर्थित है। O(log N) अनुक्रमिक R2 GET अतुल्यकालिक प्रमाण समापन बिंदु पर केवल से संबंधित हैं - कभी भी सील हॉट पथ (§16.10) या प्रति-टिक क्रोन पर नहीं।

16.10 R2-फर्स्ट एक्ट ऑर्डरिंग

कार्यान्वित POST /api/v1/upload अनुक्रम है:

1. फ्रंट-हाफ गेट्स (ऑथ, सत्यापन, इडेम्पटेंसी शार्ड कुंजी) - अपरिवर्तित।
2. सटीक व्यक्तिगत Arweave लेनदेन बनाएं, टैग करें और हस्ताक्षर करें। यह स्थानीय रूप से tx_id प्राप्त करता है, हालांकि लेनदेन निर्माण गेटवे से इनाम/एंकर मेटाडेटा प्राप्त कर सकता है। एक तैयारी विफलता अभी भी पावती से पहले अनुरोध को विफल करती है।
3. समकालिक रूप से चयनित कलाकृतियों को qub-cache/<tx_id> पर लिखें और स्थिर निर्माण-संचालन/आउटबॉक्स रिकॉर्ड को बनाए रखें। ये स्थायित्व और पुनः प्रयास मंजिल हैं; निपटान से पहले विफलताएँ 503 लौटती हैं।
4. जब LOG_DO कॉन्फ़िगर किया जाता है, तो सिंक्रोनस रूप से प्रयास LogDO.append(leaf)। एकल लेखक seq असाइन करता है, प्रविष्टि श्रृंखला का विस्तार करता है, और सीमा को अद्यतन करता है। RPC केवल यही करता है; बैच क्लोज़ अलार्म पर ऑफ-पाथ चलाता है। एक परिवहन/अनुप्रयोग विफलता वर्तमान में fail-soft है: प्रतिक्रिया अभी भी log_seq, receipt या anchor_status के बिना सफल हो सकती है। कार्यान्वयन टिप्पणी के बावजूद, कोई स्वचालित बाद में लॉग समाधान आज वायर्ड नहीं है।
5. पावती लौटाएं। { log_seq, anchor_status: "pending", receipt } केवल तभी शामिल करें जब परिशिष्ट ने पूर्ण सफल टपल लौटा दिया हो। रसीद हस्ताक्षरकर्ता अनुपलब्ध होने पर receipt.sig_b64url खाली होता है; ग्राहकों को उस मूल्य को हस्ताक्षरित या गैर-अस्वीकार करने योग्य नहीं कहना चाहिए। टपल की अनुपस्थिति का अर्थ है केवल टिकाऊ प्रकाशन, न कि पारदर्शिता-लॉग स्वीकृति।
6. सटीक हस्ताक्षरित लेनदेन पोस्ट करने के लिए एक आस्थगित कार्य का उपयोग करें। सफलता आउटबॉक्स को हटा देती है; विफलता इसे बाध्य नाली क्रॉन के लिए छोड़ देती है और पहले से स्वीकृत tx_id को नहीं बदलना चाहिए। अनंतिम मेटाडेटा और अन्य सर्वोत्तम प्रयास वाले साइडकार भी स्थगित कर दिए गए हैं।

विलंबता सीमा. अनुरोध पथ में फ्रंट-हाफ अथॉरिटी/कोटा कार्य, लेनदेन की तैयारी/हस्ताक्षर, टिकाऊ R2 लिखता है, और (कॉन्फ़िगर होने पर) LogDO प्रयास शामिल है। < 300 ms डिज़ाइन समीक्षा में एक परिचालन लक्ष्य के रूप में दिखाई देता है, प्रोटोकॉल गारंटी नहीं; वर्तमान लेनदेन-तैयारी चरण गेटवे मेटाडेटा अनुरोध कर सकता है। विलंबता अलार्म और लॉन्च गेट परिचालन नियंत्रण हैं, सत्यापनकर्ता के लिए उपलब्ध सबूत नहीं।

16.11 ट्रस्ट मॉडल - सटीक दावा, पत्ती प्रकार द्वारा स्कोप

kind=0x01 (प्रमाणित): *"यह सामग्री - बॉडी मैचिंग body_hash, जिसे qub_id द्वारा पहचाना गया है - स्थिति seq पर क्यूब के परिशिष्ट-केवल लॉग के लिए प्रतिबद्ध था और T के बाद में अस्तित्व में नहीं था; यह क्रिप्टोग्राफिक रूप से तब तक अपठनीय था जब तक कि R = unlock_round(unlock_at) में नहीं आ गया। * यह पूर्ण {tlock round binding + Merkle inclusion + anchored root} ट्रिपल है।

kind=0x02 के लिए (दावा किया गया, डिफ़ॉल्ट): *"सामग्री-पता chash के साथ एक अपारदर्शी सिफरटेक्स्ट, qub_id और unlock_at का दावा करते हुए, seq स्थिति में केवल परिशिष्ट लॉग के लिए प्रतिबद्ध था और T Arweave ब्लॉक समय के बाद अस्तित्व में नहीं था। * गोल और शरीर के पैरों की आपूर्ति मौजूदा §11 .qub-बंडल सत्यापन (qub_core::unlock), नहीं द्वारा लॉग द्वारा की जाती है; नंगे प्रति-क्यूब लेनदेन पर लॉग जो जोड़ता है वह छेड़छाड़-स्पष्ट आदेश, एक भरोसेमंद ऊपरी-बाउंड प्रतिबद्धता समय और समान प्रतिरोध है।

दोनों दावों को बाहर किया गया है, प्रति §11: sig_alg ≥ 0x01, इरादे और उप-एंकर-ग्रैन्युलैरिटी समय के बिना लेखकत्व। न तो किसी भी दावे को received_at पर झुकने देता है।

**दावा सीमा (बाध्यकारी लॉन्च बाधा - हल §16.15 Q1)। ** एक दावा (kind=0x02) पत्ती के लिए, ऊपर दिया गया स्कोप दावा छत है जो कोई भी उत्पाद, विपणन, शर्तें, या प्रूफ-रेंडरिंग सतह का दावा कर सकता है। कोई भी सतह यह नहीं बता सकती है या इसका अर्थ नहीं दे सकती है कि लॉग बाइट-ब्लाइंड अपलोड की सामग्री या अनलॉक राउंड को साबित करता है - लॉग ऑर्डरिंग + एक अपारदर्शी सिफरटेक्स्ट का एक भरोसेमंद ऊपरी-बाउंड प्रतिबद्धता समय साबित करता है। सामग्री और गोल प्रमाण विशेष रूप से मौजूदा §11 .qub-बंडल सत्यापन से आते हैं, जो लॉग-स्वतंत्र है। बिना किसी सफल परिशिष्ट/रसीद वाले प्रकाशन का कोई लॉग दावा नहीं है।

16.12 संस्करण और W3 समन्वय

कोई SealedQub वायर बंप नहीं है और इसलिए कोई प्रोटोकॉल-संस्करण बम्प नहीं है (§12.2): लॉग एक साइडकार है जो मौजूदा फ़ील्ड और बाइट्स के लिए प्रतिबद्ध है, इसलिए यह §12.3 प्रोटोकॉल-संस्करण इतिहास में प्रवेश नहीं करता है। W3 का वैकल्पिक drand_chain_version अछूता है और एकमात्र वैकल्पिक SealedQub फ़ील्ड बना हुआ है। इसके बजाय लॉग अपने स्वयं के स्वतंत्र संस्करण रिक्त स्थान - LOG_VERSION_1, ANCHOR_FORMAT_1, InclusionProof.ver - §12.5 रैपर-संस्करण स्वतंत्रता को प्रतिबिंबित करता है (रैपर प्रोटोकॉल संस्करण से स्वतंत्र एक संस्करण बाइट रखता है, और लॉग संस्करण उसी पृथक्करण का पालन करते हैं)।

** प्रूफ डिलीवरी डिफ़ॉल्ट रूप से प्राप्त की जाती है, एक वैकल्पिक राइड-साथ के साथ। ** एक सबूत सील समय पर मौजूद नहीं हो सकता है (एंकर अभी तक नहीं लिखा गया है), इसलिए बंडल .qub सील-टाइम प्रूफ-फ्री रहता है। W7 का सत्यापनकर्ता GET …/proof एक बार प्राप्त करता है, या पूरी तरह से ऑफ़लाइन मोड में Log-Id पर Arweave क्वेरी के माध्यम से सार्वजनिक AnchorBundle से प्रमाण का पुनर्निर्माण करता है। .qub बंडल (W7) एक वैकल्पिक inclusion_proof सदस्य आरक्षित करता है - सील पर अनुपस्थित, कोल्ड आर्काइवल के लिए पोस्ट-एंकर री-एक्सपोर्ट द्वारा पॉप्युलेट किया जाता है - W3 के drand_chain_version के समान "वैकल्पिक, डिफ़ॉल्ट रूप से छोड़ा गया, एडिटिव" पैटर्न का पालन करता है।

16.13 प्रतिधारण

LogDO ओपन टेल, R2 प्रूफ-सर्विंग सब्सट्रेट, एंकर सर्किट-ब्रेकर काउंटर और बंडलर फ़ॉलबैक कतार के लिए रिटेंशन विंडो docs/DATA-RETENTION.md में निर्दिष्ट हैं। सिद्धांत: लॉग का गर्म प्रति-प्रवेश भंडारण (LogDO) पुनः प्राप्त करने योग्य पोस्ट-एंकर है; इसकी ऑडिट सामग्री - मर्कल-नोड स्टोर (level, index) समन्वय-कुंजी + seq-संबोधित लीफ बॉडी (§16.9) + Arweave एंकर - स्थायी है। डीओ से एक ठंडे पत्ते को पुनः प्राप्त करना कभी भी जारी किए गए प्रमाण को अमान्य नहीं करता है, क्योंकि एक प्रमाण उस स्थायी R2 नोड स्टोर और Arweave एंकर के खिलाफ हल हो जाता है, न कि DO (और §16.9 वाइप्ड-डीओ टेस्ट वेक्टर इसे साबित करता है)।

16.14 टेस्ट वैक्टर

W5 क्रॉस-लैंग्वेज फिक्स्चर tlog_v1.json (§16.8) प्लस वर्क्ड वैक्टर शिप करता है: एक kind=0x01 और एक kind=0x02 लीफ → leaf_hash; 5-पत्ती संचयी जड़; एक समावेशन प्रमाण; एक स्थिरता प्रमाण; एक AnchorBundle; और एक डेटाआइटम आईडी। ये §14.5 बाहरी-रैपर वैक्टर के साथ रहते हैं और रस्ट (qub-core) और टाइपस्क्रिप्ट (वर्कर) कार्यान्वयन दोनों द्वारा प्रयोग किए जाते हैं।

16.15 समीक्षा निर्णय (W5 — हल किया गया)

W5 बाहरी समीक्षा (एक प्रतिकूल डिज़ाइन पास + मालिक साइन-ऑफ) पूरा हो गया है। नीचे दिया गया प्रत्येक निर्णय तय किया गया है और ऊपर दिए गए §16 पाठ में परिलक्षित होता है; बाध्यकारी लॉन्च बाधाएं अंत में फिर से बताई जाती हैं। उनके तहत कार्यान्वयन आगे बढ़ सकता है।

1. **डिफ़ॉल्ट-पथ (kind=0x02) पत्ती की ईमानदारी - हल किया गया। निर्दिष्ट के रूप में दो-पत्ती-प्रकार के विभाजन को शिप करें: kind=0x02 न तो body_hash और न ही drand_round करता है। बाइट-ब्लाइंड पथ पर कोई *_body_hash फ़ील्ड नहीं है (यह इंटीग्रेटर्स के लिए सबसे सुपाठ्य गलत "सत्यापित" संकेत होगा और एक सुविधा §11 पहले से ही बंडल से प्रदान करता है)। नहीं को लॉग-सत्यापित क्यूब्स के लिए सर्वर-सील की आवश्यकता होती है (जो वर्कर के माध्यम से प्लेनटेक्स्ट को मजबूर करेगा और क्रिप्टो-श्रेडिंग खाई को नष्ट कर देगा)। कोई भी स्व-वर्णन शॉर्ट-सर्किट .qub बंडल/प्रूफ लिफाफे में सत्यापनकर्ता-पुनर्गणना क्षेत्र के रूप में आता है, कभी भी पत्ती क्षेत्र नहीं। मालिक-पुष्टि की गई दावा सीमा: §16.11।

2. **इक्विवोकेशन/चूक जवाबदेही - डिज़ाइन हल किया गया, प्रावधान अधूरा। ** डिज़ाइन के लिए सील-रसीद कुंजी को LogProfile में पिन करने और anchor_owner द्वारा क्रॉस-हस्ताक्षरित करने की आवश्यकता होती है, साथ ही मॉनिटर पद्धति, पिछली-श्रृंखला वॉक और दोहरे स्व-प्रकाशित सिर होते हैं। संकलित प्रोफ़ाइल और परिनियोजन हुक अभी भी §16.6 में विस्तृत प्लेसहोल्डर/वैकल्पिक हैं, इसलिए मजबूत पता लगाने योग्य + प्राप्त दावा तब तक चालू नहीं होता जब तक कि वे द्वार बंद न हो जाएं। इसे कभी भी स्वतंत्र रूप से गवाही के रूप में विपणन नहीं किया जाना चाहिए। एक सच्चे तृतीय-पक्ष गवाह को §15 शासन टक्कर के लिए स्थगित कर दिया जाता है।

3. **पिन किए गए एंकर-मालिक ट्रस्ट रूट + रोटेशन - हल किया गया। ** LogProfile पिन (§16.6) को अपनाएं; सत्यापनकर्ता anchor_tx.owner == anchor_owner की जांच करता है और स्थानीय रूप से बाध्यकारी → tx_id TX डेटा की पुष्टि करता है। रोटेशन गवर्नेंस एक §15 निर्माण के लिए एक्सटेंशन (§15.3 ट्रिगर जोड़ा गया) है, पुन: उपयोग नहीं; नियोजित घुमाव क्रॉस-साइन, समझौता-संचालित घुमाव कांटा चेक बाउंडिंग क्षति के साथ §15 टक्कर पर वापस आ जाते हैं।

4. **निजी-क्यूब लीफ ब्लाइंडिंग - हल किया गया। ** निजी क्यूब (ref = SHA3-256(qub_id ‖ log_blind_secret)), सार्वजनिक क्यूब के लिए कच्चे qub_id (पहले से ही §16.2.1), chash स्टैंडअलोन टाई के रूप में अंधा करते रहें। log_blind_secret एक सहसंबंध/सिबिल-ग्रेड रहस्य है, केवल आगे की ओर घुमाएं (§16.2.1)।

5. **received_at - हल किया गया। ** इसे पत्ती में रखें, प्रतिबद्ध लेकिन स्पष्ट रूप से गैर-साक्ष्य; कभी भी किसी भी सतह पर सबूत या विवाद पुष्टि के रूप में सामने नहीं आया। कोई भी मॉनिटर विवेक जांच Arweave ब्लॉक समय T के खिलाफ तुलना करती है, न कि ऑपरेटर-नियंत्रित anchored_at (§16.6) के खिलाफ।

6. **टियर्ड प्रोविबल-टाइमिंग - डिज़ाइन रिज़ॉल्यूशन, वर्तमान रूटिंग नहीं। ** समीक्षा की गई डिज़ाइन बैच किए गए टियर को एंकर-ब्लॉक टाइमिंग और भुगतान किए गए T3 को सटीक-घंटे का प्रमाण प्रदान करता है, जिसमें पूर्व के लिए कोई संख्यात्मक SLA नहीं है। वर्तमान मार्गों ने उस व्यावसायिक अंतर को वायर्ड नहीं किया है: वे प्रत्येक स्वीकृत प्रकाशन के लिए एक व्यक्तिगत लेनदेन शेड्यूल करते हैं, और लॉग कवरेज सशर्त रहता है जैसा कि §16.1/§16.10 में कहा गया है। उत्पाद प्रति को कार्यान्वयन का वर्णन करना चाहिए, न कि इस भविष्य के स्तर के विभाजन का।

7. वर्करों पर संचयी वृक्ष — निपटाया गया। एकल संचयी RFC 9162 वृक्ष + फ्रंटियर-कैश्ड सिंगल-राइटर LogDO (लगभग 1k लिखावट/सेकंड DO सीमा के मुकाबले आरामदायक हेडरूम; मर्कल-ऑफ-शार्ड-रूट्स शार्डिंग को इसे करीब आने तक टालें)। समन्वय-कुंजी वाले (level, index) R2 नोड स्टोर + वाइप्ड-DO ठंडा-पत्ती परीक्षण वेक्टर लागू हैं (§16.9)। < 300 ms अभी भी डिज़ाइन/संचालन लक्ष्य है, प्रोटोकॉल वादा नहीं (§16.10)।

8. ANS-104 हस्ताक्षर योजना + डीप-हैश — निपटाया गया। RSA-PSS (सिग प्रकार 1, समर्पित एंकर-वॉलेट JWK का पुनः उपयोग); Ed25519 को §15 PQ पथ पर स्थगित किया गया। हैंड-रोल्ड SHA-384 डीप हैश दोनों-दिशाओं क्रॉस-इम्प्लीमेंटेशन फिक्स्चर, केवल स्थिर संदर्भ-बंडल इंटरऑप चेक, साझा-crypto.subtle राउंड-ट्रिप, और पोस्ट-बंडल Arweave-स्वीकृति मॉनिटर (§16.8) पर आधारित है।

बाध्यकारी लॉन्च बाधाएं (कार्यान्वयन + उत्पाद/कानूनी समीक्षा में ले जाएं):

• दावा सीमा (Q1/Q6). कोई भी सतह यह नहीं कह सकती है कि लॉग साबित करता है एक दावा किए गए पत्ते की सामग्री या अनलॉक राउंड; सफलतापूर्वक लंगर डाले गए kind=0x02 पत्ती के लिए अनुमत दावा आदेशित, छेड़छाड़-स्पष्ट रूप से, एक भरोसेमंद ऊपरी-बाउंड प्रतिबद्धता समय के साथ है। रसीद टपल के बिना प्रतिक्रिया का कोई लॉग दावा नहीं है। कोई टाइमस्टैम्प कॉपी संख्यात्मक विलंबता गारंटी नहीं देती है।
• गवाह ईमानदारी (Q2). बाजार समानता पता लगाने योग्य + प्राप्त, कभी भी स्वतंत्र रूप से गवाही।
• रसीद + एंकर कुंजियाँ (Q2/Q8). गैर-अस्वीकृति/एंकर-सत्यापन दावों को शिप करने से पहले, रसीद सार्वजनिक कुंजी को प्रोविज़न और कंपाइल-पिन करें, इसे प्रोविज़न किए गए एंकर मालिक के साथ क्रॉस-साइन करें, और एंकर वॉलेट को अपलोड वॉलेट से अलग अपने स्वयं के JWK के रूप में रखें।
• डीप-हैश गेट (Q8). कोई एंकर या T3 tx जहाज नहीं जब तक कि दोनों-दिशाओं की स्थिरता + इंटरॉप चेक पास न हो जाए; विफलता पर स्वीकृति मॉनिटर पृष्ठ।
• भंडारण पूर्व शर्त (Q7). समन्वय-कुंजी वाले नोड स्टोर + वाइप्ड-डीओ कोल्ड-लीफ वेक्टर "रिक्लेमेशन कभी भी सबूत को अमान्य नहीं करता है" गारंटी के लिए आवश्यक शर्तें हैं।

17. पोर्टेबल सत्यापन बंडल (.qub)

स्थिति। यह अनुभाग कार्यान्वित है (W7 / UP-C2): qub_core::export बंडल बनाता और parse करता है, और tools/qub-verify सार्वजनिक, self-contained CLI है जो इसे offline सत्यापित करता है। §11 और §16.9 पहले ही “.qub bundle” को standalone verifier द्वारा उपभोग की जाने वाली unit कहते हैं; यह अनुभाग उसके bytes और verification walkthrough को निर्दिष्ट करता है। यह strictly additive है—bundle मौजूदा §11 inputs को package करता है और कोई on-chain wire format नहीं बदलता।

17.1 उद्देश्य

§11 स्थापित करता है कि कोई भी तृतीय पक्ष qub के सहयोग के बिना उसके cryptographic artifact को सत्यापित कर सकता है। .qub bundle उस सत्यापन को portable और offline बनाता है: यह sealed CBOR और उसे unlock करने वाले drand round signature को एक self-contained artifact में रखता है, ताकि प्राप्तकर्ता बिना किसी network call के (कोई storage fetch, live drand request या qub API नहीं) content integrity, round binding और किसी भी authorship signature को सत्यापित कर सके। अकेला bundle यह सिद्ध नहीं करता कि उसका ciphertext कब बनाया गया; स्वतंत्र रूप से सत्यापित storage transaction या anchored log proof अलग existence-time दावा देता है (§11, §17.5)।

17.2 बंडल प्रारूप

QubBundle §3.1 profile के अंतर्गत hand-written canonical CBOR है (definite-length, कोई tags या floats नहीं, shortest-form integers, NFC text, optional fields अनुपस्थित होने पर omitted, keys encoded-byte length ascending फिर bytewise क्रम में)। तीन 15-character keys d < i < s क्रम में हैं। कच्ची .qub file बिल्कुल यही bytes है; URL या copy-paste transport के लिए इन्हीं bytes का base64url(no-pad) उपयोग होता है।

drand_round और drand_chain_id, sealed_qub_cbor के convenience projections हैं, ताकि tooling inner CBOR parse किए बिना उन्हें पढ़ सके। निर्माण पर वे derived होते हैं और decode पर parsed sealed qub के विरुद्ध दोबारा जाँचे जाते हैं; top-level field और payload असहमत होने पर bundle अस्वीकार होता है। Encoder discipline शेष wire format जैसी है: खाली drand_signature या arweave_tx_id अस्वीकार करें और हर variable-length field को bound करें।

17.3 embedded drand हस्ताक्षर क्या सिद्ध करता है

Bundle verifier को fetch कराने के बजाय drand signature साथ रखता है। Timelock decryption (drand chain पर tlock, §8) केवल बँधे round के वास्तविक beacon signature से सफल हो सकता है—ऐसा मान जिसे chain उस round के बीतने के बाद ही प्रकाशित करती है और जो chain की public key के अंतर्गत valid BLS signature है। forged या ग़लत signature BLS verification या IBE/AEAD decryption में विफल होता है। इसलिए decrypt होने वाला bundle सिद्ध करता है: ciphertext round R से बँधा है और round R बीत चुका है। Verifier chain (DrandTimelockProvider::quicknet()) pin करता है और §11 round-binding check लागू करता है, इसलिए bundle ऐसा round claim नहीं कर सकता जिससे उसका ciphertext बँधा न हो।

यह release-condition proof है, creation timestamp नहीं। Round R बीतने के बाद कोई भी R के लिए नया ciphertext बना सकता है और उसके पहले से सार्वजनिक signature को package कर सकता है। इसलिए अकेले bundle को यह प्रमाणित करने वाला MUST NOT कहा जाए कि ciphertext या content R, unlock_at, या किसी event से पहले मौजूद था।

17.4 ऑफ़लाइन सत्यापन walkthrough

qub-verify <file.qub> pinned DrandTimelockProvider से qub_core::unlock::unlock चलाकर मानक §11 प्रक्रिया पूरी तरह bundle से चलाता है:

1. Parse the .qub bytes → QubBundle (canonical-CBOR guard; bound every field;
   re-check drand_round / drand_chain_id against the embedded sealed qub).
2. BLS-verify bundle.drand_signature for the pinned chain and round, then
   tlock_decrypt(sealed.tlock_ciphertext, bundle.drand_signature) → QubEnvelope.
3. Verify SHA3-256(body) == body_hash               (§11 step 8).
4. Verify QubEnvelope.qub_id   == SealedQub.qub_id   (§11 step 9).
5. Verify QubEnvelope.unlock_at == SealedQub.unlock_at (§11 step 10).
6. Verify ciphertext round == unlock_round(unlock_at) and the chain binding.
7. If sig_alg != 0x00: verify author_signature (and any cosigner; §9.4).
8. Report integrity, round-elapsed/round-binding, authorship, and cosigner
   verdicts separately, plus the recovered body. Do not report a commitment
   timestamp unless step 9 succeeds.
9. Optional existence-time leg: verify an included §16 proof through its pinned
   anchor, or independently verify the referenced storage transaction. Report
   its block time as an upper bound on ciphertext existence.

CLI 0 (verified), 1 (verification failed—अभी locked, body-hash mismatch, टूटा round/chain binding या असत्यापित signature), या 2 (usage / malformed bundle) से exit करता है। --json report automation के लिए वही verdicts रखती है। Bundle self-contained होने से verifier crate (qub-core) और CLI (qub-verify) ही किसी तृतीय पक्ष को आवश्यक software हैं; दोनों public हैं और protocol के मौजूदा verification path को reuse करते हैं—कोई bespoke crypto नहीं।

17.5 पारदर्शिता लॉग से संबंध

inclusion_proof, §16 Merkle inclusion proof के लिए वैकल्पिक slot है। Bundle-only verification (§17.4) integrity, round binding / round elapsed और वैकल्पिक authorship के लिए पूर्ण है, लेकिन जानबूझकर कोई independently timestamped existence claim नहीं रखता। भरा हुआ, पूरी तरह anchor-verified inclusion_proof, bundle format version बदले बिना §16.11 की leaf-kind-specific commitment और upper-bound time जोड़ता है। अनुपस्थित proof का अर्थ केवल “कोई proof शामिल नहीं”—“invalid” नहीं और आवश्यक नहीं कि “anchored नहीं”।

Reference implementation में slot अब typed है: qub_core::export::QubBundle::inclusion_proof_typed() उसी opaque CBOR field के माध्यम से पूर्ण §16.9 structure (leaf, audit path, anchored root और AnchorRef) रखने वाला Option<InclusionProof> लौटाता है—कोई bundle-format version bump नहीं। Standalone qub-verify CLI इसे अपने --anchor leg से उपयोग करता है और—anchor wallet provision होने तक (§16, स्थिति)—populated-but-placeholder-owner proof को fully anchored-verified के बजाय inclusion-only रिपोर्ट करता है।