qub samskiptareglulýsing

qub er samskiptaregla fyrir dulritaðar tímaskuldbindingar: kerfi til að innsigla orð við framtíðardagsetningu og síðar staðfesta nákvæmlega hvað var innsiglað, hvaða drand-lota stýrði losun þess og—þegar geymslufærsla eða sönnun úr gagnsæisskrá er tiltæk—sjálfstætt tímastimpluð efri mörk þess hvenær dulritunartextinn var skuldbundinn.

Þrjár grunneiningar gera þetta mögulegt. drand er dreifður tilviljanaviti—birtingardagsetningunni er framfylgt dulritunarlega en ekki af velvild qub. Endingargóð geymsla ásamt gagnsæisskrá sem aðeins er bætt við varðveitir innsigluðu bætin og festir hópskuldbindingar í varanlegri opinberri geymslu; greidda T3-leiðin skrifar einnig einstaka færslu í varanlega geymslu. ML-DSA-65 er eftir-skammtafræðileg stafræn undirskrift—þegar höfundareign er virkjuð er qub-inn bundinn lyklapari þar sem leyndarlykillinn yfirgefur aldrei tæki höfundarins.

Saman gera þessar grunneiningar yfirlýsingu sem er tímalæst og auðsjáanlegt ef átt er við hana, má rekja valfrjálst til höfundar og má tímastimpla sjálfstætt—kvittun sem verður verðmætari eftir því sem geta heimsins til að falsa fortíðina batnar.

Það sem eftir er af þessu skjali er hin staðlaða útfærsluforskrift sem þarf til samvirkrar útfærslu.

qub samskiptareglu-forskrift

Þetta skjal er staðlaða samskiptareglu-forskriftin fyrir qub tímaskuldbindingakerfið. Það skilgreinir gagnabyggingar, raðtalningarreglur, afleiðsluformúlur og staðfestingaraðferðir sem nauðsynlegar eru fyrir samvirka útfærslu.

Umfang: samskiptareglulagið er viljandi tungumálahlutlaust — qub líkaminn er ógagnsær texti / markdown / sáttmála bitar, og staðlingameðvituð birting er á ábyrgð lesandans (qub.social vefforrit, <qub-embed> iframe, MCP biðlarar, o.s.frv.).

1. Táknun og venjur

Allar heiltölur í forhneppingum eru kóðaðar sem big-endian bætafylki af fastri breidd (i64 → 8 bæti, u8 → 1 bæti) nema annað sé tilgreint.

Allir tímastimplar eru Unix sekúndur í UTC.

2. Gagnabyggingar

2.1 ComposeQub (staða höfundar í minni)

Ekki raðtalin í CBOR. Ekki skrifuð í varanlega geymslu. Staðbundin höfundarforritinu.

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 (afkóðaður burður)

Raðtalin með kanónískri CBOR (§3). Dulkóðuð innan SealedQub. Þetta er byggingin sem sannar heilleika innihalds eftir afkóðun.

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
}

Grunngerð (óundirritaður texta-qub): version = 0x01, content_type = 0x01, sig_alg = 0x00; undirskriftar- og meðundirritarareitir eru fjarverandi. Aðrir valfrjálsir lýsigagnareitir mega vera til staðar.

Aðrar v1 stillingar: content_type = 0x03 (sáttmála líkami, sjá §6.1); sig_alg = 0x01 (ML-DSA-65) með author_signature og author_pubkey til staðar (sjá §9.3); cosigner_pubkey og cosigner_signature saman til staðar fyrir meðundirritaða sáttmála (sjá §9.7); reply_to sett á qub_id foreldris fyrir svar-keðjur (sjá §9.3 fyrir afleiðingar á undirskriftarumfangi).

2.3 SealedQub (kanóníska þráðarsnið)

Raðtalin með kanónískri CBOR (§3). Þetta er innri þráðagripurinn: við opinbera afhendingu eru þessi bæti geymd óumbúin en við einkaafhendingu eru þau sett í OuterWrapper fyrir geymslu (§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 (lesandi forritsstaða)

Ekki raðtalin í CBOR. Staðbundin lesandaforritinu. Smíðuð eftir vel heppnaða afkóðun og staðfestingu.

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. Kanónískt CBOR snið

Öll raðtalning SealedQub og QubEnvelope SKAL fylgja þessu sniði. Tvær útfærslur, gefin sama rökrétta bygging, SKULU framleiða eins bæti.

3.1 Kóðunarreglur

3.2 Staðfestar kanónískar lyklaraðir

Þessar lyklaraðir eru staðlaðar. Útfærslur SKULU senda lykla nákvæmlega í þessari röð. Aflúsunarstaðhæfingar ÆTTU að staðfesta röðunina í non-release smíðum.

QubEnvelope (útgáfa 0x01, óundirritað, allir valfrjálsir reitir fjarverandi):

"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)

Afleiðsla lyklaraðar QubEnvelope: hver lykill er CBOR textastrengur. Kóðuð lengd = 1 bæti haus + lengd strengs (fyrir strengi undir 24 bætum). Raða eftir heildar kóðaðri lengd fyrst, síðan stafrófsröð fyrir lykla af sömu lengd.

SealedQub (útgáfa 0x01, opinber, enginn móttakandi):

"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 (sáttmála líkami, 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 (röð í terms fylki):

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

PartyIdentifier (party_a / party_b kort):

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

3.3 Tilvísun bæta-kóðunar

4. Staðlaðar afleiðslur

4.1 qub_id

qub_id auðkennir qub einkvæmt og bindur QubEnvelope við SealedQub. Það er afleitt á ákveðinn hátt frá innihaldi umslagsins.

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

Kóðun lénsskiljara: Strengurinn "QUB_ID_V2" er 9 ASCII bæti. Einu 0x00 fyllingarbæti er bætt við til að ná 10 bætum í jöfnun. Útfærslur SKULU nota nákvæmlega þessi 10 bæti: [0x51, 0x55, 0x42, 0x5F, 0x49, 0x44, 0x5F, 0x56, 0x32, 0x00].

Kóðun outcome_at: Útfærslubreyting fyrir útgáfu lengdi formyndina úr 92 bætum í 100 bæti til að fella valfrjálsa reitinn outcome_at inn í bindinguna. Fjarverandi outcome_at er kóðað sem 8 núllbæti; samskiptaregluvottendur hafna outcome_at <= 0 alls staðar, þannig að þetta vörðugildi getur ekki rekist á lögmætt gildi. Sjá §3.2 (vírsnið) og innanhúss-skjalið tasks/verdict-uplift-plan.md fyrir úrskurðarvirknina sem hvetur til þessa reits.

Kóðun drand_round: Síðari útfærslubreyting fyrir útgáfu lengdi formyndina úr 100 í 108 bæti til að fella drand_round (drand-marklotuna, §4.3) inn í bindinguna og breytti lénsskiljaranum í QUB_ID_V2. Þetta bindur tímaláslotuna við auðkenni qub-sins: gátt getur ekki endurbundið dulritunartextann við aðra lotu (til dæmis þegar liðna) en birta unlock_at gefur til kynna. Aflæsingaraðferðin (§8) staðfestir einnig að lotan í tlock-dulritunartextastönzunni passi við unlock_round(unlock_at), svo hægt er að sanna að birta opnunartímanum sé stýrt af þeirri lotu sem raunverulega stýrir afkóðun.

Eiginleikar:

• Breyting á hvaða reit sem formyndin bindur—version, content_type, created_at, unlock_at, outcome_at, drand_round, hráum body-bætum (í gegnum body_hash) eða title (í gegnum title_hash)—framleiðir annað qub_id.
• qub_id er reiknað fyrir dulkóðun. Bæði QubEnvelope og SealedQub bera sama qub_id. Lesandinn staðfestir að þeir passi saman eftir afkóðun.
• qub_id er ekki háð sender_label, reply_to, undirskriftarbætum eða opinberum undirritunarlyklum. Í núverandi V2-undirritunarsmíð eru sender_label og reply_to hins vegar auðkennd beint með sender_label_hash og reply_to_or_zero (§9.3) þegar undirskriftir eru til staðar.
• Breyting á SealedQub title (með öllu öðru föstu) breytir qub_id í gegnum title_hash. Gátt getur því ekki skipt út hreina-texta titlinum sem birtist á niðurtalningunni án þess að ógilda qub auðkennið.
• Breyting á SealedQub outcome_at (með öllu öðru föstu) breytir qub_id í gegnum forhassið. Gátt getur ekki skipt út niðurstöðudagsetningunni sem birtist á niðurtalningunni fyrir birtingu án þess að ógilda qub auðkennið.
• Breyting á drand_round (með öllu öðru föstu) breytir qub_id í gegnum forhassið. Gátt getur ekki endurbundið tímalás-dulkóðunartextann við aðra lotu án þess að ógilda qub auðkennið; ásamt stanza-lotu-athuguninni við aflæsingu í §8 er birti unlock_at sú lota sem raunverulega stýrir afkóðun.

4.2 body_hash

body_hash = SHA3-256(body)

Þar sem body er hrár Vec<u8> innihaldsburður. Fyrir textaqub er þetta UTF-8 kóðaður qub líkami.

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

Þar sem title er valfrjáls hrein-texti titill sem birtist á niðurtalningu lesandans fyrir birtingu (sjá §3.2). NFC-stöðlun fer fram við tætireikning svo tætið sé stöðugt yfir sjónrænt jafngildar kóðapunktaraðir. Allt-núll sjenta er frátekið fyrir fjarverandi tilfellið; tómur strengur er hafnað á kanónísku CBOR mörkunum sem ókanónísk kóðun á "fjarverandi" (kanóníska kóðunin sleppir reitnum alveg).

4.3 Vörpun aflæsingarumferðar

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

Þetta er viðmiðunarkortlagning tlock (CurrentRound hjá drand). drand birtir lotu N á chain_genesis_time + (N - 1) * chain_period_seconds, þannig að formúlan velur lotuna sem er gild við unlock_at—lotuna þar sem undirskriftin er sú fyrsta sem lesandi sem kemur við unlock_at getur notað.

Jöfnunareiginleiki (tilfellið sem skiptir máli í reynd): þegar (unlock_at - chain_genesis_time) er nákvæmlega deilanlegt með chain_period_seconds er undirskrift valinnar lotu birt nákvæmlega við unlock_at, aldrei fyrr. Þetta gildir alltaf um viðmiðunaruppsetninguna: upprunatími quicknet (1692803367) er deilanlegur með þriggja sekúndna tímabili hennar og viðmiðunarforritin festa opnunartíma við heilar mínútur. Fyrir unlock_at sem er ekki jafnað birtist undirskrift valinnar lotu innan við einu tímabili fyrir unlock_at—tímaleg nákvæmni skuldbindingarinnar er eitt vitatímabil.

Eldri kortlagning fyrir útgáfu og vikmörk við aflæsingu: Upprunalega kortlagningin var ceil((unlock_at - chain_genesis_time) / chain_period_seconds), sem—í jafnaða tilfellinu hér að ofan—valdi lotuna sem birtist einu heilu tímabili fyrir unlock_at og gerði dulritunartextann afkóðanlegan nákvæmlega einu tímabili of snemma. Kortlagningarnar tvær munar nákvæmlega +1 þegar mismunurinn er deilanlegur með tímabilinu en þær eru annars eins. Þar sem drand_round er fellt inn í óbreytanlega qub_id-formynd (§4.1) er ekki hægt að endurleiða gripi sem voru innsiglaðir með eldri kortlagningunni; vottendur sem framkvæma lotuathugun §8 skrefs 6a SKULU því samþykkja geymt drand_round sem er annaðhvort leidd lota eða leidda lotan mínus einn (og SKULU krefjast þess að tlock-stanza-lotan sé nákvæmlega jöfn geymdu lotunni). Vikmörkin færa elstu mögulegu stýriundirskrift að hámarki um eitt tímabil. Biðþjónusta sáttmála beitir sömu vikmörkum þegar hún endurleiðir qub_id biðsáttmála (við biðsetningu og meðundirritun): ef núverandi kortlagning endurgerir ekki skuldbundna qub_id og mismunurinn er deilanlegur með tímabilinu reynir hún aftur með lotunni mínus einum og innsiglar fullgerða sáttmálann við þá lotu sem qub_id raunverulega bindur—aldrei í blindni við endurreiknuðu lotuna, sem myndi gera gripinn varanlega óendurleiðanlegan.

Staðfesting: unlock_at SKAL vera í framtíðinni á innsiglunartíma. unlock_at SKAL EKKI vera meira en 10 ár frá created_at (til að takmarka langtíma drand áhættu; notendaviðmótið ÆTTI að vara við aflæsingardagsetningum lengra en 2 ár í burtu).

5. Þráðarsniða nýtegundir

Þráðarsniða nýtegundir veita öryggi á þýðingartíma gegn því að rugla CBOR bætum saman við JSON, hreinan texta, eða aðrar bætakóðanir.

5.1 Smíðareglur

// 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 Staðfesting við smíði

from_encoded() ÆTTI að staðfesta að inntakið byrji á gildum CBOR korta-haus. Full byggingarleg staðfesting gerist á þátta-tíma, ekki smíða-tíma, til að forðast tvíþáttun.

6. Skráning innihaldsgerða

Lesendur SKULU hafna óþekktum innihaldsgerðum með skýrri notenda-sýnilegri villu. Lesendur SKULU EKKI reyna að birta óþekktar gerðir sem texta.

6.1 Sáttmála líkami (content_type = 0x03)

Sáttmála líkami er kanóníska CBOR kóðun á PactTerms gildi:

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)> }

Kanónískar CBOR lyklaraðir fyrir öll þrjú kortin eru gefnar í §3.2. Heildar raðtalaður sáttmála CBOR SKAL EKKI fara yfir 100 KB (passar við §6).

Hluttegundargreinir. Fyrsta röðin í terms fyrir structured/v1 sáttmála SKAL vera { key: "pact_schema", value: "structured/v1" }. Raðir án þessa merkis eru "sérsniðnir" sáttmálar og fá enga byggingarstaðfestingu eða hluttegundarmeðvitaða birtingu.

Frystar viðurkenningarrifur. structured/v1 sáttmálar bera nákvæmlega fjórar viðurkenningarraðir undir þessum lyklum:

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

value fyrir hvern er einn af átta frystum enskum strengjum valinn eftir (role, kind) pari, þar sem role ∈ { seller, buyer, provider, client } og kind ∈ { standard, capacity }. Strengirnir sjálfir eru stöðluð samskiptareglu-gögn — ML-DSA-65 undirskriftir beggja aðila skuldbinda sig við nákvæmu bætin í gegnum body_hash. Þeir eru EKKI staðfærðir; undirritaður líkami er tungumálahlutlaus. Allar orðabreytingar krefjast nýrrar hluttegundarútgáfu (structured/v2).

Strengirnir átta, uppfletting þeirra (acknowledgement_for(role, kind)), og rökstuðningur fyrir hverjum eru festir af viðmiðunarútfærslunni. Samsvarandi útfærslur SKULU senda bætaeins viðurkenningargildi; gullfestu SHA3-256-body_hash-prófin sem þekja öll fjögur hlutverkasambönd grípa alla breytingu.

Birtingarröð lesandans. Viðurkenningarstrengirnir innihalda orðasambönd eins og "lýst að ofan", sem gera ráð fyrir að lýsingar / umfangs raðir birtist á undan viðurkenningunum. Lesendur SKULU birta terms fylkið í CBOR röð; endurröðun brýtur merkingu textans.

Móttakanda samband. Þegar contact Party B er gilt tölvupóstfang, sendir qub upphlaðningarþjónustan sjálfkrafa skoðunar- / meðundirritunarboðspóst á sviðsetningartíma og bindur að lokum meðundirritunina við staðfestingu sama heimilisfangs (§9.7). Sáttmálar þar sem samband Party B er fjarverandi geta enn verið meðundirritaðir, en aðeins um band-utan rás — þjónustan hafnar meðundirritunarbeiðnum sem geta ekki framleitt samsvarandi 15-mínútna tölvupóst-staðfestingarmerki.

6.2 Úrskurðar líkami (content_type = 0x04)

Úrskurðar líkami er kanóníska CBOR kóðun á VerdictBody gildi:

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
}

Kanónísk CBOR lyklaröð:

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

Heildar raðtalaður úrskurðar CBOR SKAL EKKI fara yfir 8 KB (passar við skráningarröðina hér að ofan).

Útkomu-enum. Vír-bætið er ætlunarhlutlaust; flokkarnir fjórir Right / Partial / Wrong / Unfalsifiable ná yfir útkomurými sérhverrar úrskurðar-berandi ætlunar. Per-ætlun merkingar ("Rétt spáð" / "Stóð við það" / "Afgreitt" / "Staðfest" fyrir Right, o.s.frv.) eru birtingaratriði lesandans, leyst gagnvart ætlun foreldris-qub-sins — vírinn helst tungumáls- og ætlunarhlutlaus. Gildum utan 1..=4 SKAL hafnað við afkóðun.

Foreldris-tengsl. Úrskurðar-qub ber EKKI foreldris-tilvísunina í líkama sínum. Arweave-færslu-auðkenni foreldris-qub-sins er gefið út sem Parent-Tx-Id geymslumerki á upphlaðningartíma (§7 geymslumerkja-lag). Þetta heldur líkamanum sem sjálfstæðri undirritaðri yfirlýsingu um sjálfsmat; endurskoðunarkeðjan ("rétt um hvað?") er staðfest með Arweave-merkja uppflettingu.

Öryggi sönnunar-URL (skuldbindandi). Þegar evidence_url er til staðar, SKULU staðfestar (innsiglunarhlið, vír-hlið, Worker brún) framfylgja:

1. Aðeins HTTPS. Strengurinn SKAL byrja á bæta-runu https://. Allar aðrar samskiptareglur — http, ftp, javascript, data, file, o.s.frv. — er hafnað.
2. Lengdarþak. ≤ 2.048 bæti (vafraskráhámark í reynd).
3. NFC + óvinveittra-kóðapunkta athugun. Sama regla og fyrir title og reflection — bidi-yfirskrift / núll-breidd / merkjablokk / BOM / C0 / C1 kóðapunktum er hafnað. Skilgreining passar við Rust crate::handle::contains_hostile_text_codepoint og TS workers/api/src/utils/unicode.ts::isHostileCodepoint (haldið í samspili).
4. Engin auðstaf, engin ASCII stýring. Auðstaf / DEL / undir-0x20 bætum hvar sem er í URL-inu er hafnað — lokar \n/\t innspýtingar-vektornum sem bidi reglan nær ekki yfir.
5. Ekki-tómt hýsil-hluti. Allt á milli https:// og fyrsta /, ?, eða # SKAL vera ekki-tómt.

Engin þjóns-hliðar sókn. Worker SKAL EKKI proxa, sækja, eða forskoða URL-ið. Samskiptareglan geymir streng; birting gerist lesanda-megin með rel="nofollow noopener noreferrer" target="_blank" og sýnilegum hýsil birtum samhliða tengill-texta.

Íhugun. Valfrjáls höfundar-ritaður íhugunartexti ("hvað breyttist, hvað lærðir þú"). Sama NFC + óvinveittra-kóðapunkta staðfesting og fyrir title. Tómt / aðeins-auðstafa inntak fellur niður í fjarverandi á smíðatíma.

Hluttegundarútgáfa. v1 styður aðeins verdict_version = 0x01. Framtíðar hluttegundarendurskoðanir hækka þetta bæti og lenda samhliða nýrri samskiptareglu-útgáfu samkvæmt §12.

7. Innsiglunarregla

Full innsiglunarröð. Hvert skref er staðlað.

 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.

Geymslumerkjalag (utan bands). Upphleðsluþjónusta qub festir vísvitandi lítið mengi geymslufærslumerkja við valinn upphleðsluburð. Content-Type=application/octet-stream er staðlað krafa. Viðmiðunarþjónustan festir auk þess þrjú valfrjáls merki þegar höfundur velur að sýna þau: Intent (samsetningarásetningur sannreyndur gegn nákvæma leyfislistanum announcement, thesis, prediction, letter, secret, commitment, proof, eða kerfisútgefna gildinu verdict), Author (§9.3 fingrafar dreifilykils höfundar sem 64 stafa lágstafa hex), og Parent-Tx-Id (geymslufærsluauðkenni foreldris-qub fyrir svarkeðjur, 43 stafa base64url).

Author merkið er opt-in fyrir hvern qub: viðmiðunar höfundarforritið festir það aðeins þegar notandi virkar opinbera rekjanleika beinlínis á innsiglunartíma. Þegar rofinn er af — sjálfgildið — er ekkert Author merki skrifað og qub er órekjanlegur á keðjunni: ekkert í varanlegri geymslu tengir upphlaðninguna við handle, tölvupóst, eða aðra qub höfundar. Þegar rofinn er á, leysist Author fingrafarið í valinn @handle höfundar í gegnum §9.5 staðfestingakeðjuna. Svar-keðju sambönd og Intent eru ekki auðkennandi. Við einkaafhendingu dulkóða ytri umbúðirnar (§13) auðþekkjanlega innri SealedQub-gripinn, svo söfnun geymdra umbúða og öflun opinberra drand-undirskrifta duga enn ekki til að endurheimta líkamann án K; geymslumerki eru áfram vísvitandi opinber lýsigögn.

Viðmiðunarþjónustan festir vísvitandi EKKI App-Name, App-Version, eða Type merki: hvert slíkt einnar gildis sía myndi skila öllum qub korpus til GraphQL fyrirspurnar, sem stangast á við líkamans-eingöngu trúnaðarumfang umbúðanna.

Samsvarandi staðfestingaraðili SKAL EKKI byggja á neinu geymslumerki fyrir §11 þriðju aðila staðfestingu; líkamstæti / qub_id / undirskrift skuldbindur sig aðeins við innri CBOR, aldrei merkjamengið.

8. Aflæsingarregla

Full aflæsingarröð. Hvert skref er staðlað.

 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. Höfundar-undirritun

9.1 Rökstuðningur

qub eru geymd í varanlegri geymslu. Höfundar-undirskriftir verða að halda áfram að vera ófalsanlegar að eilífu, sem er ástæðan fyrir því að v1.0 notar eftir-skammtafræðilegu ML-DSA-65 aðferðina (FIPS 204) frekar en klassíska aðferð þar sem öryggi gæti rýrnað innan varanlegrar líftíma qub.

9.2 Skráning algríms

Lesendur samskiptareglu v1 SKULU hafna hverju gildi utan {0x00, 0x01}, þar með talið frátekna gildinu 0x02. Frátekning kemur í veg fyrir endurnotkun fyrir slysni; hún virkjar ekki aðferðina. Virkjun hennar krefst stjórnuðu breytingarinnar sem lýst er í §15.

9.3 Smíði undirritaðs forhneppingar

Tvær útgáfur forhneppingar hafa verið til. Allar undirskriftir SKULU nota V2, og staðfestingaraðilar SKULU aðeins samþykkja V2. Eldri V1 forhneppingin (skjalfest hér að neðan til sögulegrar viðmiðunar) var samþykkt sem varaleið eingöngu við staðfestingu meðan á flutningi yfir í V2 stóð; sú varaleið hefur verið tekin úr notkun og undirskrift sem aðeins stenst V1 er nú hafnað.

V2 (núverandi — framleitt af allri nýrri höfundar-undirritun, og af báðum undirskriftum í sviðsetningar- / meðundirritunarflæði sáttmála):

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 fylgir sömu fjarveru-gildisvenju og title_hash (§4.2.1): 32 núllbæti eru ekki gilt SHA3-256 úttak, svo „fjarverandi" getur aldrei rekist á fyrirliggjandi merkimiða. Allir reitir eru fastrar breiddar, svo forhneppingin er ótvíræð án lengdarforskeyta.

V1 (eldri — TEKIN ÚR NOTKUN; ekki lengur framleidd og ekki lengur samþykkt við staðfestingu):

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 forhneppingin sleppti sender_label og reply_to. Hún var samþykkt sem varaleið eingöngu við staðfestingu meðan á flutningi yfir í V2 stóð; sú varaleið hefur síðan verið tekin úr notkun — staðfestingaraðilar SKULU aðeins samþykkja V2 forhneppinguna. Skilgreiningin er varðveitt hér til sögulegrar viðmiðunar og til að útskýra lénsskiljarann hér að neðan. Undirskrift sem aðeins stenst staðfestingu gegn V1 SKAL meðhöndlast sem staðfestingarbrestur.

Lénsskiljarar: "QUB_AUTHOR_SIG_V1" / "QUB_AUTHOR_SIG_V2" eru 17 ASCII bæti hvor ([0x51, 0x55, 0x42, 0x5F, 0x41, 0x55, 0x54, 0x48, 0x4F, 0x52, 0x5F, 0x53, 0x49, 0x47, 0x5F, 0x56, 0x31/0x32]). Engin fylling. Ólíki skiljarinn lén-aðgreinir smíðarnar tvær, svo undirskrift yfir aðra forhneppinguna getur aldrei staðfest sem hin.

org_id_present bæti: bætið sem fylgir unlock_at SKAL vera 0x00. Viðmiðunarútfærslan birtir þetta sem fastann ORG_ID_PRESENT_INDIVIDUAL = 0x00 í crates/qub-core/src/signing.rs; lesendur sem endurbyggja sig_input fyrir staðfestingu SKULU senda sama bætið.

Umfang undirskriftar — hvað er hulið og hvað ekki. V2 sig_input skuldbindur sig beint við version, qub_id, body_hash, unlock_at, sender_label, og reply_to (auk fasta lénsskiljarans og org_id_present bætisins). qub_id er sjálft afleitt frá version, content_type, created_at, unlock_at, outcome_at, drand_round, og body_hash í gegnum §4.1 forhneppinguna, svo öll breyting á þessum reitum framleiðir annað qub_id og ógildir undirskriftina yfir tilfærslu. Beint-staðfest yfirborðið er því:

Hvers vegna V2 er eina samþykkta forhneppingin.

• Undir hinni úreltu V1 forhneppingu gæti aðili með skrifaðgang að geymdum bætum skipt um sender_label ("Alice" → "Mallory") eða endur-foreldrað reply_to — og endurdulkóðað eftir umferð — án þess að ógilda höfundar-undirskriftina, því hvorugur reiturinn var í undirritaðu forhneppingunni. V2 nær yfir báða, svo öll breyting á öðrum hvorum reitnum snýr staðfestingu í „mistókst". Þar sem staðfestingaraðilar samþykkja nú aðeins V2, er þessi umskipting lokuð fyrir hverja undirskrift: undirskrift sem bindur hvorugan reitinn (þ.e. stenst aðeins staðfestingu gegn V1) er hafnað hreint út frekar en lækkað niður í hana.
• author_pubkey innan umslagsins er enn hið raunverulega auðkennisakkeri — lesendur SKULU leiða birtingarauðkenni af author_pubkey (í gegnum §9.5 staðfestingarlagið) frekar en að treysta sender_label.

Útfærslur sem birta sender_label eða reply_to til endanotenda SKULU sýna staðfest auðkenni (opinber lykils fingrafar, staðfesting) sem aðal auðkennismerki, ekki merkimiðann.

9.4 Staðfestingaraðferð

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."

Staðfesting undirskriftar er dýrasta aðgerðin (sérstaklega ML-DSA-65). Hún ÆTTI að vera framkvæmd eftir að allar ódýrari athuganir (tæti, qub_id, unlock_at) hafa staðist.

9.5 Auðkennisstaðfestingar

Auðkennisstaðfestingar — vörpun á author_pubkey í mannlæsileg auðkenniskröfur eins og qub handle, tölvupóstfang, samfélagsmiðla handle, eða passkey skilríki — eru lesanda-megin framsækin viðbót og eru ekki nauðsynlegar fyrir undirskriftarstaðfestingu. Lesendur sem leysa staðfestingar í birtingarauðkenni SKULU beita forgangi:

handle > email > social > fingerprint

Fingrafars varaleið er lágstafa hex af SHA3-256(author_pubkey); það er alltaf tiltækt fyrir hvert undirritað qub. Lesendur MEGA stytta það fyrir birtingu — viðmiðunarlesandinn birtir qub: og þar á eftir fyrstu og síðustu fjögur bætin (qub:<8 hex>…<8 hex>).

Samsvarandi staðfestingaraðili getur lokið hverri athugun í §9.4 án þess að hafa samband við qub API, án nokkurs netkerfis umfram varanlega geymslu og drand, og án nokkurrar miðlara-megin uppflettingar. Staðfestingaúrlausn er aðskilið besta-átaks skref framkvæmt aðeins eftir að undirskriftarstaðfesting hefur tekist.

9.6 Stærðaráhrif

Fyrir textaqub upp á 500–2.000 bæti þrefaldar ML-DSA-65 nokkurnveginn geymda stærðina. Heildarkostnaður er hverfandi.

9.7 Staðfesting meðundirritara (sáttmála tvíhliða samkomulag)

Fyrir tvíhliða samkomulag (content_type = 0x03), sannar annað undirskriftarlag að báðir aðilar samþykktu sömu skilmála.

Umslagsreitir:

• cosigner_pubkey: ML-DSA-65 opinber lykill meðundirritarans (Party B).
• cosigner_signature: Undirskrift yfir sama sig_input og höfundur (§9.3).

Báðir reitir SKULU vera til staðar saman eða báðir fjarverandi. Ef nákvæmlega einn er til staðar SKULU lesendur tilkynna heilleikavillu.

Staðfestingaraðferð:

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."

Eiginleikar:

• Meðundirritarinn undirritar sama sig_input og höfundurinn — báðir aðilar skuldbinda sig við sama qub_id, body_hash, og unlock_at (og, undir V2, sama sender_label_hash og reply_to_or_zero).
• Til að meðundirritarinn geti endurbyggt V2 forhneppinguna án aðgangs að hráum umslagsbætunum, framfylgir sviðsetningarþjónustan á sviðsetningartíma því að sender_label sáttmálaumslags sé jafnt pact_terms.party_a.label og að reply_to sé fjarverandi. Hvort tveggja gildir fyrir hvern viðmiðunarbiðlara-sáttmála; umslög sem brjóta þetta er hafnað við sviðsetningu.
• qub_id afleiðsla (§4.1) inniheldur EKKI meðundirritarreiti. Að bæta meðundirritara við fyrirliggjandi umslag breytir ekki qub_id.
• Sáttmáli getur verið aðeins höfundar-undirritaður (einhliða skuldbinding), aðeins meðundirritari (óvenjulegt), eða bæði (full tvíhliða sönnun).

Tölvupóstsbindingarhlið (rekstrarlegt). Þegar sviðsettur sáttmáli ber Party B-tölvupósttengilið (§6.1), SKAL upphleðsluþjónusta qub hafna meðundirritunarbeiðninni nema skammlíft tölvupóstsstaðfestingarmerki sé til sem samsvarar bæði sviðsetningarauðkenni og tæti staðlaðs tölvupóstfangs tengiliðarins. Merkið er skrifað af /api/v1/auth/verify þegar auðkenni töfratengilsins ber staging_id og staðfesta netfangið samsvarar SHA-256(normalise_email(party_b.contact)) — þar sem normalise_email(addr) varðveitir há-/lágstafi staðarhlutans og setur aðeins lénshlutann í lágstafi (samkvæmt RFC 5321 §2.3.11), og SHA-256 hér er NIST FIPS 180-4-tæti (aðgreint frá SHA3-256 sem notað er í §4-afleiðslum) — og rennur út 900 sekúndum (15 mínútum) eftir útgáfu. Þetta er rekstrarleg vörn gegn brottfalli, EKKI hluti af sönnun qub á keðjunni — þriðja aðila staðfestir sem endurspilar §11 þarf aðeins varanlega geymslu og drand, án nokkurrar uppflettingar miðlaramegin. Merkið er aðeins til miðlaramegin og er aldrei hluti af undirritaða líkamanum.

Stærðaráhrif (ML-DSA-65 höfundur + meðundirritari):

10. Markdown birting og hreinsun

Þessi hluti er öryggis-mikilvægur. Lesandinn birtir textaqub (content_type = 0x01) með takmarkað Markdown hlutmengi.

10.1 Leyfðir þættir

• Fyrirsagnir: # til #### (ekki ##### eða ######)
• Áhersla: feitletrun (**), skáletrun (*), yfirstrik (~~)
• Listar: númeraðir (1.) og ónúmeraðir (-, *)
• Tilvitnanir (>)
• Kóði: innbyggðar línur (```) og afmarkaðar blokkir (`````)
• Lóðréttar línur (---)
• Línuskil (tvö lokabil eða auð lína)
• Málsgreinar

10.2 Bannaðir þættir

10.3 Útfærsla

Útfærslur SKULU nota strangan heimilislista-þáttara, ekki bannlista. Mælt með aðferð:

1. Þátta Markdown með pulldown-cmark (eða jafngildu).
2. Gangaðu yfir AST og slepptu öllum hnúti sem er ekki á heimilislistanum (§10.1).
3. Fyrir tengla-hnúta: sendu URL sem sýnilegan texta, ekki sem smelltanlegan <a> þátt.
4. Breyttu síaða AST yfir í tegundavarið milliform (t.d. MarkdownNode enum með aðeins öruggum afbrigðum). Hrátt HTML er byggingarlega ósýnilegt í þessu IR.
5. Birttu frá tegundavarna IR yfir í markaðsýn (t.d. viðbragðs view-hluti, DOM hnúti). Engin HTML strengjasamtenging eða innerHTML á neinum tímapunkti.

Bannlista aðferðir eru viðkvæmar vegna þess að nýjar Markdown viðbætur eða þáttarasvíkjur geta innleitt ósíaða þætti. Tegundavarin-AST aðferðin gerir XSS byggingarlega ómögulegt — það er ekkert afbrigði sem getur borið handahófskennt HTML.

10.4 Stærðar- og byggingartakmörk

• Hámarks birt fyrirsagnardýpt: #### (H4). ##### og dýpri eru birt sem feitletraður texti.
• Engin takmörk á málsgreinafjölda (líkamsstærðartakmörk í §6 eru hindrunin).
• Afmarkaðar kóða blokkir: engin málfræðisliturarmerking í MVP. Birtar sem fastbreiddur forformaður texti.

11. Þriðju aðila staðfesting

Hver þriðji aðili sem hefur geymdu bætin (og K fyrir einkarekinn/umluktan qub) getur staðfest dulritunargripinn án samvinnu qub. Sjálfstætt tímastimpluð fullyrðing um tilvist krefst að auki annaðhvort staðfestrar einstakrar færslu í varanlegri geymslu eða staðfestrar sönnunar úr gagnsæisskrá §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.

Hvað staðfesting sannar:

Hvað staðfesting EKKI sannar:

Útfærða gagnsæisskráin (§16) bætir staðfestingu milli qub við með breytingarsýnilegri röðun og traustlausum efri mörkum skuldbindingartíma (blokktíma festingarinnar), afmörkuðum eftir blaðtegund (§16.11). Hún bætir hvorki við höfundareign né ásetningi; fyrir sjálfgefnu bætablindu upphleðsluleiðina sannar hún ekki sjálf body_hash eða drand_round, sem koma áfram úr gripathugunum.

12. Útgáfustjórnun og útgáfueftirlit

Skjalaútgáfur, innri vírsamskiptareglan og ytri umlykjan eru aðskilin útgáfurými. Skýring sem aðeins varðar skjalið breytir því ekki bætum þegjandi og framtíðar vírflutningur getur ekki dulbúist sem ritstjórnarbreyting.

12.1 Skjalaútgáfa

Þessi forskrift notar merkingarbærar skjalaútgáfur (MAJOR.MINOR.PATCH) og óbreytanlegt Git-merki sem nefnist protocol-v<release>.

• PATCH: Nákvæmnis- eða ritstjórnarleiðrétting sem breytir hvorki samhæfum bætum né áskilinni hegðun.
• MINOR: Afturvirkt samhæf staðlað viðbót, ný skráningarfærsla eða nýtt sjálfstætt útgáfustýrt hliðarsnið.
• MAJOR: Ósamhæf staðlað breyting, þar með talin ný áskilin túlkun vírsniðs.

Útgáfustaða er annaðhvort Drög (ekki enn staðlað), Gildandi (eina ráðlagða útfærslumarkmiðið) eða Leyst af hólmi (varðveitt fyrir sögulega staðfestingu). Óútgáfumerkta leiðin /samskiptaregla birtir gildandi útgáfu; útgáfumerkið varðveitir nákvæman frumtexta hennar og hvert tungumál sem var gefið út með henni. Breyting á stöðu eða útgáfunúmeri krefst þess að þessi tafla og útgáfusagan séu uppfærð í sömu yfirförnu breytingu.

12.2 Samskiptaregluútgáfa

version reiturinn (u8) í bæði SealedQub og QubEnvelope auðkennir aðal-útgáfu samskiptareglunnar.

• Lesendur SKULU hafna óþekktum aðal-útgáfum með skýrri villu.
• Innan þekktrar aðal-útgáfu SKULU afkóðarar hafna óþekktum korta-lyklum (§3.1) — hluttegundarþróun gerist með því að innleiða nýtt version, ekki með því að bæta við lyklum sem fyrirliggjandi afkóðarar myndu hunsa. (Fyrri endurskoðanir þessarar forskriftar leyfðu að þola óþekkta valfrjálsa reiti; það ákvæði er afturkallað — það gerði vörpunina encode(decode(x)) óeintæka og opnaði vektor fyrir falið undirritað efni í sáttmála-líkömum.)
• Innihaldsgerðir (content_type) og undirskriftaraðferðir (sig_alg) eru útgáfu-bundnar: nýjum gildum má aðeins koma fyrir samhliða nýrri samskiptareglu-útgáfu eða skýrri skráningar-uppfærslu.

12.3 Saga samskiptaregluútgáfa

12.4 Framvirk samhæfni

v1 lesandi sem rekst á QubEnvelope með óþekkta CBOR korta-lykla (lyklum ekki í §3.2 kanónísku röðinni) SKAL hafna umslaginu með afkóðunarvillu (§3.1). Framvirk samhæfni hvílir á version reitnum, ekki á lykla-umburðarlyndi: framtíðar viðbætur — jafnvel smávægileg lýsigögn — koma út undir nýju version gildi, sem v1 lesandi hafnar með skýrri „nýrri samskiptaregla“ villu frekar en að fella þegjandi niður efni sem undirskriftirnar skuldbinda sig við.

v1 lesandi sem rekst á sig_alg = 0x01 (ML-DSA-65) en skortir ML-DSA-65 staðfestingarstuðning ÆTTI að birta qub innihaldið með „undirskrift til staðar en ekki staðfestanleg“ tilkynningu, ekki að hafna qub alveg. Viðmiðunarútfærslan í dag hafnar hverju sig_alg gildi öðru en 0x00 og 0x01 vegna þess að v1 skráningin inniheldur ekkert annað gilt algrím — strangt höfnun og mjúk-bilun eru athugunarlega eins þangað til þriðja algrími er skráð. Mjúk-bilunarhegðunin að ofan verður burðar-berandi þegar §9.2 viðurkennir nýja færslu, og viðmiðunarlesandinn verður uppfærður til að mjúk-bila á þeim tímapunkti.

12.5 Útgáfa ytri umlykju

OuterWrapper sem lýst er í §13 ber sitt eigið version bæti, sjálfstætt frá SealedQub.version og QubEnvelope.version. Útgáfu-rýmin tvö þróast aðskild: framtíðar eftir-skammtafræðilega-örugg samhverf útskipting hækkar umbúða bætið án þess að snerta innri samskiptareglu-útgáfuna, og framtíðar samskiptareglu-lags viðbót (t.d. nýr umslagsreitur) hækkar innri útgáfuna án þess að snerta umbúða bætið.

Lesendur SKULU hafna óþekktum umbúða útgáfum með skýrri villu. Samskiptareglan heldur vísvitandi umbúða útgáfu-rýminu þröngu þar til áþreifanlegur flutnings drifkraftur birtist (t.d. NIST leiðbeiningar sem hygla annarri AEAD); 0x02 rifa verður úthlutuð í sömu endurskoðun og innleiðir algrímið.

13. Ytri dulkóðunar umbúðir

13.1 Rökstuðningur

Samskiptareglu-lögin (QubEnvelope → tlock → SealedQub) gera innsiglaðan qub tímalæstan: líkaminn er ólæsilegur þar til unlock_at og drand umferðar undirskriftin hefur verið birt. Eftir aflæsingu er hins vegar umferðar undirskriftin opinber og kanóníska CBOR lögun SealedQub þekkjanleg, svo uppskerumaður sem flokkaði geymslufærslur gæti fjöldaafkóðað allan qub korpus.

Fyrir einkarekna afhendingu loka ytri dulkóðunarumbúðirnar þeirri rás með því að setja aukið samhverft AEAD-lag á milli kanóníska SealedQubCbor og geymdu bætanna. Í vafrainnsiglunarleiðinni býr 256-bita lykillinn K aðeins í URL-broti afhendingar-URL-sins og á notendatækjum; vafrar senda ekki URL-brot til þjóna, svo qub.social, allar geymslugáttir og öll CDN fyrir framan þau sjá ekki K. Geymda framsetning einkarekins qub-s er því ógagnsær dulritunartexti þar sem hreinn texti er óendurheimtanlegur án URL-sins sem höfundurinn valdi að deila. Opinber afhending sleppir þessu lagi vísvitandi (§13.8).

Nettóáhrif:

• Talningarviðnám fyrir einkaafhendingu. OuterWrapper er áfram auðþekkjanlegt skipulagt CBOR—það er ekki bókstaflega óaðgreinanlegt frá handahófskenndum bætum—en dulritunarreitur þess felur auðþekkjanlega innri SealedQub-lögun. Skráða uppskeruaðferðin að "GraphQL-fyrirspyrja um óumbúin qub-laga upphlöð og magn-afkóða með opinberum drand-undirskriftum" endar ekki með hreinum texta án K.
• Dulkóðunartæting í sjálfgefna einkarekna vafraflæðinu. qub.social getur ekki afkóðað þessa geymdu gripi út frá sjálfgefnum gögnum sínum á miðlarahlið. Bein endurheimt, opinber afhending og traust innsiglun á miðlarahlið hafa önnur, upplýst traustmörk.
• Tveggja-laga trúnaðar stigi. Sjálfgildi = tengla-stýrður aðgangur (þessi hluti). Móttakanda-dulkóðuð einka qub (frátekinn eiginleiki í áfanga 2, enn óskilgreindur) leggjast ofan á sem annað lag.

13.2 Lögun

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

Innsiglun og aflæsing á samskiptareglu-laginu (§7, §8) eru óbreytt undir umbúða-mörkunum; umbúðirnar festast við kallstað seal() og losna við kallstað unlock().

13.3 OuterWrapper gagnabygging

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
}

Reita-invariantar.

• version SKAL vera jafnt 0x01 fyrir v1.0 umbúða bæti.
• qub_id SKAL vera jafnt qub_id-reit þess SealedQub sem endurheimtist eftir afpökkun. Bæði viðmiðunar-föllin wrap_sealed_qub og unwrap_sealed_qub þátta innra CBOR og framfylgja þessum jöfnuði beint; AAD-bindingin veldur sjálfstætt því að breyting á ytra qub_id eftir umbúðir fellur á auðkenningu.
• nonce SKAL vera 96 bita (12 bæti), framleitt ferskt af CSPRNG fyrir hverja umbúða aðgerð. Að endurnýta nonce undir sama lykli leyfir AEAD nonce-endurnýtingar árásir sem endurheimta hreinan texta; framleiðendur SKULU meðhöndla (key, nonce) pör sem eins-skotsupphæð.
• ciphertext er AES-256-GCM úttak: dulkóðunar bæti samtengd 16-bæta sönnunarmerkinu. ciphertext.len() == SealedQubCbor.len() + 16 nákvæmlega.

CBOR kóðun. Kanónísk CBOR samkvæmt §3, með sömu lyklaröðunarreglu (raðað eftir kóðaðri bætalengd hækkandi, síðan stafrófsröð). Fjórir lyklarnir eru:

Fyrsta bæti OuterWrapper CBOR er því ákveðin-lengdar korta haus fyrir 4-færslu kort (0xA4).

13.4 AAD binding við qub_id

Umbúðirnar binda qub_id sem AEAD viðbótar staðfest gögn. Þetta er burðar-berandi byggingarvörnin gegn þremur árásarflokkum:

Að bera qub_id í hreinum texta umbúðanna veikir ekki viðnám gegn upptalningu merkjanlega — qub_id er sjálft SHA3-256-tæti af §4.1-forímynd án endurheimtanlegrar forímyndar úr tætinu, og upptalningaraðili sem þegar hefur safnað umbúðabætunum lærir ekkert af sýnilega qub_id sem ekki mætti þegar álykta út frá tilvist upphleðslunnar sjálfrar.

13.5 Umbúða og af-umbúða algrími

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

Bilunar-hams samhrun. Rangt K, rangt nonce, AAD ósamsvörun, og átta dulkóðunartexti framleiða allt sömu DECRYPT_FAILED villu. Þetta er vísvitandi AEAD eiginleiki: að aðgreina bilunar-haminn myndi skapa hliðar rás sem fjar árásarmaður gæti rannsakað með því að senda gallaðar umbúðir og tímamæla viðbragðið. Viðmiðunarútfærslur SKULU hrynja allar AEAD bilanir saman í eina villu lögun.

13.6 Lyklaefni og dreifing

Umbúða lykillinn K er 256-bita einsleitt handahófskennt gildi framleitt fyrir hvern qub af CSPRNG. Viðmiðunarútfærslurnar fá það frá:

• WASM höfundur: getrandom (WebCrypto undir wasm_js bakenda).
• Kallandi miðlara-megin innsiglunar-API: staðbundinn CSPRNG hans; kallandinn útvegar og heldur K sem wrapper_key_b64url. Worker notar K í minni fyrir umbúðirnar en SKAL EKKI varðveita hann. Þetta gerir idempotent endurtilraun kleift að endurheimta ritskoðað svar með varðveittri heimild kallandans í stað þess að reiða sig á eins-skots leyndarmál sem þjónninn framleiðir.

Dreifing: K SKAL kóðað sem URL-örugg base64 (RFC 4648 §5, engin fylling) og bætt við afhendingar URL sem brot íhlut:

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

Brotið er aldrei sent til neins miðlara af samsvarandi vafra. Endurheimtarrásir (miðlara-megin saga skrá, opt-in tölvupósts sjálfsending) sem viðhalda fullum afhendingartengli — þar með talið brotinu — utan tækis notandans eru skýrt skipti á sjálfgefnu dulkóðun-tætings stöðunni og SKULU vera bundnar við skýrt samþykki notanda.

Tap brots. Ef notandi tapar URL brotinu og hefur enga endurheimtarrás, er qub ólæsilegt. Þetta er burðar-berandi skipti hönnunarinnar og SKAL upplýst um til notandans á innsiglunartíma. MVP styrkir innsiglunar-tíma upplýsingarnar með skýru "geyma þessa URL" texta og staðfest-tölvupósts endurheimtarrás fyrir notendur sem skrá sig inn.

13.7 Utan-umfangs fyrir þennan hluta

• Höfundar-undirritun (§9) er óbreytt: undirskriftir eru reiknaðar innan innra QubEnvelope og endurheimtist eftir af-umbúð → tlock afkóðun → CBOR þáttun.
• Dulkóðun með opinberum lykli viðtakanda (fráteki reiturinn recipient_pubkey) er framtíðareiginleiki sem er aðskilinn frá núverandi einkarekna umlykjuhamnum sem er stýrt með tengilgetu.
• Núverandi þjónsmegin meðundirritunarflæði sáttmála gefur út opinbert/bert SealedQubCbor með sýnileika 0x01; það getur ekki uppfyllt líkan um leynd K sem takmarkast við vafra þar sem lokainnsiglun fer fram eftir þjónustumiðlaða meðundirritun. Framtíðar framleiðandi einkasáttmála má nota sömu umlykju, sem er bætablind gagnvart innri efnistegund.

13.8 Opinber qub (umbúðum sleppt)

Ytri umbúðirnar eru valfrjálsar á afhendingarlaginu. Höfundur má innsigla qub sem opinbert, en þá fer kanóníska SealedQubCbor beint inn í geymsluferlið, án OuterWrapper lags og án lykils K:

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

Opinbert qub er tímalæst en ekki tengla-stýrt: það helst ólæsilegt þar til drand umferð þess birtist (tlock lagið er óbreytt), en eftir aflæsingu getur hver sá sem hefur auðkenni geymslufærslunnar afkóðað það — ekkert URL brot er krafist, því það er ekkert K. Þetta eru vísvitandi skiptin fyrir fleti sem miðlarinn verður að knýja: birtingartilkynningar í tölvupósti, oEmbed-/sjálfvirkir innfellingartenglar án brots og ríkari SEO eftir birtingu þurfa allir tengil sem virkar án leyndarmáls sem miðlarinn heldur aldrei (§13.6). Einkarekinn qub getur áfram notað skýra formið <qub-embed src="full_delivery_url"> þegar útgefandinn lætur alla getuna með brotinu fylgja.

Afleiðingar sem framleiðandi SKAL gera ráð fyrir:

• Ekkert talningar-ónæmi. Opinber qub afsala sér §13.1 talningar-ónæmis eiginleikanum með smíðinni. Viðmiðunar-upphlaðningarþjónustan stimplar Visibility: public varanlegrar-geymslu merki á þau (og aðeins þau) svo þau séu vísvitandi uppgötvanleg; einka qub bera ekkert slíkt merki og halda bæta-aðgreinanleika sínum.
• Hreinn-texti titill afhjúpaður á innsiglunartíma. §3.2 title reiturinn er hreinn texti inni í SealedQubCbor. Undir umbúðunum er hann falinn þar til lesandi leggur fram K; án umbúðanna er hann heims-læsilegur í varanlegri geymslu frá augnabliki upphlaðningar, fyrir aflæsingu. Samræmd höfundar-forrit SKULU upplýsa um þetta á innsiglunartíma.
• Greining er byggingarleg og krossathuguð. Samræmdur lesandi/innfelling aðgreinir geymdu lögunirnar tvær með þáttun: bæti sem þáttast sem OuterWrapper fara um af-umbúðun-með-K leiðina; bæti sem þáttast sem bert SealedQubCbor eru samþykkt beint. Endurheimta innra gildið SKAL stemma (0x00 fyrir umlukt/einkarekið, 0x01 fyrir bert/opinbert). qub_id bindur ekki sýnileika, en kanónísku SealedQub-bætin bera hann, svo opinber og einkarekin innri kóðun eru ekki bæti fyrir bæti eins.

Einka (pakkað) helst sjálfgildið; opinbert er skýrt val höfundar fyrir hvern qub.

14. Prófunarvigrar

14.1 qub_id afleiðsla

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

Útfærslur SKULU framleiða eins body_hash og qub_id gildi fyrir þetta inntak. Þessi prófunarvigur ÆTTI að vera fyrsta einingaprófið skrifað. Kanónísku gildin að ofan voru reiknuð af viðmiðunarútfærslunni og SKULU passa bæti fyrir bæti. Sögulegar frumgerðarlaganir fyrir útgáfu (engin lifandi qub voru háð fyrstu tveimur) notuðu 92 bæti fyrir outcome_at (3d9fc2390eab043d38a1669ed3b71be76f9eefe872b9569ab1aaa027b88392b0) og 100 bæti eftir að outcome_at_or_zero var bætt við (b0d032898ad629795150fdcb3f84e518f59ed05b7a2a82bc24ebdb87f52144ed). Núverandi 108-bæta lögun bætti síðan við drand_round og lénsskiljaranum QUB_ID_V2. Snemmbúinn 108-bæta vigur notaði eldri ceil-lotukortlagninguna (drand_round = 4695445) og gaf 3a9fcb31b750d985c262fada6d4f777fd6a28be831d941d85c131f5a4bbaf8a4—enn gilt qub_id fyrir það lotuinntak, en dæmið að ofan fylgir núverandi lotukortlagningu §4.3.

14.2 Vörpun aflæsingarumferðar

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

Lota 4675286 er birt á 1595431050 + (4675286 - 1) * 30 = 1735689600—nákvæmlega við unlock_at, aldrei fyrr. (Eldri ceil-kortlagning fyrir útgáfu gaf 4675285, birt á 1735689570—30 sekúndum of snemma; vottendur samþykkja þá eldri lotu samkvæmt §4.3.)

14.3 Kanónísk CBOR hringferð

Útfærslur SKULU staðfesta að serialize(parse(serialize(qub))) == serialize(qub) fyrir öll gild inntök. Þetta er eiginleika-próf, ekki einn vigur.

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)

Kanónísku CBOR bætin og SHA3-256 body_hash eru reiknuð af viðmiðunarútfærslunni. Útfærslur SKULU framleiða byte-eins CBOR fyrir þetta inntak.

Útfærslur SKULU einnig staðfesta að serialize(parse(serialize(pact))) == serialize(pact) fyrir öll gild PactTerms inntök (eiginleika-próf).

14.5 Ytri umbúða þvert-á-tungumál vigrar

Ytri umbúðirnar (§13) hafa sérstaka kanóníska fastingu á crates/qub-core/tests/vectors/wrapper_v1.json. Hvert tilvik festir (key, nonce, qub_id, sealed_cbor) túplu sem ógagnsæ hex inntök og staðfestir tiltekið expected_wrapper_hex úttak. Báðar viðmiðunarútfærslur neyta sömu JSON skrár:

• 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).

Festingin skilgreinir nú þrjú lágstigs umbúðatilvik. Þau prófa ákveðna OuterWrapper-kóðun og AEAD-víxlvirkni óháð afhendingarsniðskröfunni í §13.8; einkum gera sögulega heitið basic-text-public og innri visibility = 0x01 þess ekki umbúðuðu bætin að samræmdri opinberri afhendingu. Framleiðandi VERÐUR enn að geyma opinber innri bæti óumbúin og umlykja aðeins einkabæti (0x00).

Útfærslur SKULU framleiða byte-eins expected_wrapper_hex fyrir skráð inntök. Að endurskapa festinguna krefst QUB_REGEN_VECTORS=1 cargo test -p qub-core --test wrapper_vectors og er frátekið fyrir vísvitandi sniða breytingar.

15. Stjórnun dulkóðunar-sniðs (framtíð)

Þessi hluti er upplýsandi fyrir v1 og verður staðlaður í fyrsta sinn þegar annað algrími kemur inn í einhverja af dulkóðunar grunneiningum qub.

15.1 Núverandi staða

Samskiptaregla v1 bindur nákvæmlega eitt algrími á grunneiningu:

• Undirskrift: ML-DSA-65 (sig_alg = 0x01; 1952-bæta opinber lykill, 3309-bæta undirskrift) og óundirritað (sig_alg = 0x00). Kóðagrunnurinn frátekur 0x02 fyrir Ed25519, en samskiptaregla v1 virkjar það ekki; v1-vottandi SKAL hafna hverju sig_alg utan {0x00, 0x01}.
• Tímalás: aðeins drand quicknet — keðjutæti, dreifilykill, upphafstími og tímabil eru fastar netbreytur sem viðmiðið DrandTimelockProvider::quicknet() (crates/qub-core/src/tlock.rs) og config/drand-endpoints.json bera.
• Ytri umbúðir: AES-256-GCM v1 aðeins (§13).

Vottendur harðkóða nú lykla- og undirskriftarstærðir fyrir hverja virka grunneiningu. sig_alg- og umlykjuútgáfubætin eru skýrir veljarar, en v1 semur ekki um neitt innan bands og leyfir aðeins virku gildin að ofan.

15.2 Ætluð lögun

Þegar annað algrími kemur inn í samskiptaregluna, verður staðfestingaraðilinn stilltur fyrir nafngreint CryptoProfile (t.d. ExqubV1) sem lista nákvæma mengi af leyfðum gildum á grunneiningu — sig_algs, drand keðjur, umbúða útgáfur, innihaldsgerðir. Sniðið er fast á staðfestingartíma, aldrei samið í-bandi. Hvert gildi utan virka sniðsins er hafnað.

Þetta tryggir að það að bæta við ML-DSA-87 eða virkja Ed25519 getur ekki afturvirkt veikt fyrirliggjandi staðfestingar-stillingar: v1 staðfestingaraðili er enn v1 staðfestingaraðili jafnvel eftir að v2 snið er birt.

15.3 Kveikju skilyrði

Stigjaðu §15 upp í staðlaða stöðu þegar eitthvað af eftirfarandi er stungið upp á:

• Annað sig_alg bæti (Ed25519 virkjun, ML-DSA-87, eða ný færsla í §9 skráningu).
• Önnur drand keðja í framleiðslu notkun.
• Önnur ytri-umbúða útgáfa.
• Skipti á traustrót gagnsæisskrárinnar—vistfangi LogProfile.anchor_owner eða festa opinbera kvittunarlyklinum (§16.6). LogProfile bætist við yfirborð §15.2 sem stýrð grunneining: skipti eru undirrituð LogProfile-hækkun sem er send í uppfærslu vottanda (áætluð skipti krossundirrita útleið → innleið; skipti vegna málamiðlunar geta það ekki og reiða sig á hækkunina ásamt klofningsathugun fyrri festingar til að afmarka skaða á meðan). Útgáfurými gagnsæisskrárinnar (LOG_VERSION, ANCHOR_FORMAT) þróast sem sjálfstæð systkini, rétt eins og útgáfa umlykju §12.5 er óháð samskiptaregluútgáfunni.

Þangað til er §15 staðsetningarmerki sem festir flutnings lögunina svo framtíðar PRs lendi á þekktum markmiði frekar en að endurræða samningayfirborðið frá grunni.

16. Gegnsæisskrá og endingarstig (Innleitt — yfirferð lokið)

Staða. Þessi kafli er innleiddur (W5/UP-B1, stig 1–8), með framleiðanda og traustrótarumfangi tilgreint hér. Vírsnið, hash og staðfestingarleiðir eru virkar: kjarna Merkle + kanóníska-CBOR gerðir (qub-core), TypeScript spegilinn + ANS-104 bunkarinn (workers/api/src/crypto/), einritari LogDO + hnitalykil R2 hnútageymslan, /upload tilraun til að bæta við loggum, daglegur akkeri + pakkari-drena cron, GET /api/v1/qub/:tx_id/proof (innfelling) og GET /api/v1/log/consistency (RFC 9162) sönnunarpunktar, týpubundin innlimunarsönnun sem fylgir .qub pakkanum (§17.5), innfædda ANS-104 akkerissannprófara (tools/qub-verify) og tvöfaldur sjálfútgefinn höfuðkrókur (§16.6). Árangursrík /upload er alltaf R2-varanleg en er aðeins log-þakin þegar LOG_DO er stillt og innbyggð viðbót tekst; aðeins þá ber svarið log_seq, receipt og anchor_status. Ef RECEIPT_SK er fjarverandi eða ógilt, er sig_b64url kvittunarinnar tóm og veitir enga óafneitun. Núverandi útgáfuleiðir /seal og pact skipuleggja einstakar Arweave færslur en bæta ekki við logblaði. Enginn kóði framkvæmir núna /upload tillögu um síðar samræmingu eftir að viðbætur mistakast. Ytri yfirferð W5 er lokið: §16.15 skráir hönnunarákvarðanir og ræsingartakmarkanir, en þær takmarkanir auka ekki framleiðendaþekjuna sem áður var nefnd. Þrír traust-/dreifingarhlutir eru áfram lokaðir: (a) sérstakt akkerisveski (ANCHOR_JWK; LogProfile.anchor_owner er enn [0xAB; 32] staðgengill); (b) kvittunarundirritunarlykillinn og samsvarandi opinberi lykilpininn (RECEIPT_SK er valfrjáls og LogProfile.receipt_pubkey er núna tómur); og (c) sjálfútgefna höfuð GitHub geymslan + tákn (§16.6). Þangað til festi-/prófílpinnarnir eru útvegaðir, skilar sjálfstæður sannprófunaraðili frá sönnunarstöðu heiðarlega í stað þess að fullyrða fullkomlega festa, festa staðfestingu. Hönnunin er eingöngu samlagning og engin breyting er á SealedQub / QubEnvelope vírformi.

16.1 Rökstuðningur og endingarstig

Núverandi birtingarleiðir aðskilja staðfestingu frá Arweave staðfestingu: þær leiða af og undirrita einstaka færslu, viðhalda villunni og nákvæmu innsendingarástandi í R2, og birta síðan ósamstillt. Gegnsæisloggið bætir við sjálfstætt festu röðunarlagi fyrir undirmengi almennra /upload beiðna sem LogDO viðbætur tekst:

Þrepin lýsa aðskildum sönnunar- og þolþolseiginleikum, ekki núverandi viðskiptahugmynd. Núverandi kóði skipuleggur samt einstök Arweave viðskipti fyrir hverja samþykkta birtingu; það sýnir ekki T3 aðeins sem greidda uppfærslu. API-lykla/reikningshámarkar eru áfram sérstakir stjórnunarþættir forritsins.

Þolheiðarleiki. T1-skrif eru samstillt, svo árangursríkt svar staðfestir þol á forritastigi án þess að bíða eftir Arweave hlið. Það stofnar ekki sjálfstætt tímamerki sjálft. Staðfest einstök viðskipti gefa efri takmörk blokkartíma. Fyrir svar sem ber fulla T2 kvittunarmengi, getur næstu staðfestu ankra útvegað skráarvottorð sem lýst er hér að neðan. Ef mengi er ekki til staðar, má ekki gera ráð fyrir að qub-ið sé þegar í gagnsæjaskránni. Ankra- og birtingarseinkunn hefur ekki tölulegt SLA á prótóleveli.

16.2 LogLeaf Uppbygging (tvær skuldbundnar gerðir)

Innsláttur í dagbók er LogLeaf, kóðaður sem handskrifaður kanónískur CBOR undir §3.1 prófílnum (ákveðinn lengd, engin merki, engir flotpunktar, stystu form talna, NFC texti, valkvæð reitir ekki til staðar þegar þeir vantar, lyklar raðaðir eftir kóðaðri bætiglengd í hækkandi röð og svo bytewise). Kanóníska vörðin §3.1 parse → re-encode → compare er notuð á kóðunarstígnum áður en hashing fer fram (ekki einungis við afkóðun), svo tvær útfærslur geta ekki verið ósammála um blaðbytana vegna mismunandi heiltölubreiddar eða lykilröðunar. Allar heilar tölur eru u8 / u64 / i64; allar útskrefslar eru 32-bæta bita-strengir (bstr[32]). Vistaður Arweave viðskiptauðkenni er hrátt 32-bæta SHA-256 útskrefsla flutt sem bstr[32], aldrei sem base64url textastrengur (samræmist §3.3).

Blaðið hefur tvær gerðir valdar með kind bæti, vegna þess að almenni upphleðslustígurinn er ófljótandi fyrir bæti: POST /api/v1/upload meðvitað meðhöndlar báðar samþykktu gagnageðgerðir sem ógegndræpar og tekur á móti qub_id og unlock_at aðeins sem ósannaðar staðhæfingar viðskiptavinar. Á sjálfgefnum persónulegum stíg, body_hash, drand_round, created_at og drand_chain_version eru ennfremur falin innan §13 ytri umslags, sem lykillinn hans Worker heldur aldrei. Tegundakerfið skilgreinir einnig vottaða gerð fyrir framleiðanda sem afleiðir body_hash / drand_round sjálfur. Núverandi /seal stígur inniheldur þessi gildi en kallar ekki á LogDO, svo framleiðslan framleiðir nú aðeins staðhæfðar (0x02) blöð úr velgengnu almenna upphleðsluauka. Gafflið heldur öllum skuldbundnum gildum heiðarlegum án þess að halda að vottaður framleiðandi sé víraður:

kind=0x02 lauf framkvæmir meðvitað hvorki body_hash né drand_round: það staðfestir skuldbindingu og röðun ógegnsæs dulmáls á efnis-chash, og heldur fram qub_id og unlock_at — ekki hreintexta eða hringlaga texta. Hreintexti/hringlaga fætur fyrir staðfestan qub koma frá núverandi §11 .qub-pakka staðfestingu, ekki frá loginu (§16.11). drand_chain_version er ekki í laufinu (það er inni í umbúðinni á sjálfgefnu leiðinni); keðjukorn lifa á akkerinu (§16.7). Kóðara aga: hafna all-zero ref eða chash og hafna ójákvæðum unlock_at / received_at, sem endurspeglar outcome_at > 0 sentinel guard í cbor.rs.

16.2.1 Einka-kúb-blindun

Skráin má ekki verða upptalningaroraklið sem §13 ytri umbúðin er til að koma í veg fyrir (§13.1). Fyrir einkarekinn (vafðan) qub asserted laufblaðið blindað auðkennið SHA3-256(qub_id ‖ log_blind_secret), þar sem log_blind_secret er þjónageymdur leyndarmál, og sleppir body_hash. Þriðji aðili getur ekki tengt slíkt lauf við ákveðið qub_id; eigandi qub-ins, sem hefur afhendingarvefslóðina og þar með qub_id, getur endurreiknað blindið til að staðfesta eigin innlimun sína. Opinber qub (sem þegar er talin, ber þegar Visibility: public Arweave merkið samkvæmt §13.8) framkvæmir hráa qub_id. Þetta er eina staðurinn þar sem sjálfstæð sannprófun gefur meðvitað eftir fyrir burðarberandi persónuverndaróbreytanleika; sjálfstæða tengingin fyrir einkareknar qub er chash (§16.9).

log_blind_secret vörslu (leyst — §16.15 Q4). Blindið verndar laufaftengingu, ekki trúnað í hreinum texta (§13 umbúðin heldur því sjálfstætt). Við log_blind_secret málamiðlun, fyrir hvaða qub_id sem andstæðingurinn á þegar eða getur endurbyggt (hvert qub sem hann hefur bundið/URL með, auk lág-entropíu eða opinberra qub_id) endurreiknar hann laufið ref í einum hash og tengir það — þetta er bein tenging við þekktan þýði, ekki hreint afl yfir óþekkt svæði. Flokkaðu log_blind_secret sem fylgni-/Sybil-gráðu leyndarmál í sama varðveislustigi og önnur leyndarmál netþjóna, og snúðu aðeins áfram (snúningur blindar aftur framtíðar lauf; hún getur ekki afturvirkt aftengt þau sem þegar eru fest).

16.3 Lauf- og hnútahashing

RFC 6962 §2.1 Domain-aðskilin hashing þar sem SHA-256 er skipt út fyrir 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

Viðskeytisbæti 0x02 (inntakskeðja, §16.4) og 0x03 (STH hash, §16.6) eru frátekin og ótengd frá þessum. Þau eru einstök bæti og geta því ekki rekist á núverandi 10-bæta ASCII sviðsaðskiljara (QUB_ID_V2 o.s.frv.). Tréð er RFC 6962 vinstri-fullt ójafnvægið tré (hvert innra tré skiptist á stærsta veldi tveggja nákvæmlega minna en undirtré lauffjölda), sem leyfir innsetningar- og samkvæmnissönnum að deila einu eftirlitsslóðaralgrími. Viðmiðunarforskriftin ber skýran vinstri/hægri afleiðukóða og festir ekki-veldi-af tveimur (5-laufa) prófunarvektor þannig að hægri brúnar kynningartilvikið — sem 4-laufa vigur felur — er notað.

16.4 Hash-keðja (innri)

LogDO viðheldur innri færslukeðju eingöngu til að tryggja samræmni við hrun. Það er aldrei birt og aldrei beint að sannprófara:

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

Útgefin viðaukasheimild er uppsöfnuð Merkle-rót + akkeri hennar (§16.5–16.6), aldrei hráa röðin sem virkjann þjónar laufum í: keðjan endurreiknar fyrir hvaða pöntun sem er þjónuð, þannig að aðeins festu rótarpinnarnir hafa kanóníska stöðu.

16.5 Safnað Merkle-tré og lotun

Það er eitt sívaxandi RFC 6962 tré yfir öll lauf í seq röð — ekki einangruð tré á hverja lotu. (Burðarlauf-keðja á hverja lotu var hafnað: það er ekki raunverulegt forskeyti, svo "samkvæmnissönnun" þess eru ótraust.) Safntréð gefur ekta RFC 9162 samkvæmnissönnun og leyfir einum nýlegum festi að sanna innfellingu fyrir hvaða eldri qub sem er.

LogDO varanlegi hluturinn er einn ritari (blockConcurrencyWhile, endurspeglandi QuotaDO / EntitlementDO) — að bæta við sameiginlegan logg er les-breyta-skrifa á sameiginlegu ástandi og því VERÐUR að fara í gegnum DO, aldrei KV. Það geymir hægri brún trésins (O(log n) hash) svo að loka lotu er O(batch). lota er safn laufa sem eru fest saman; útfærðir triggerar hans eru tree_size framvinda um að minnsta kosti LOG_BATCH_MAX_LEAVES (sjálfgefið 4096), aldur nær akkeri eða skýr stjórnsýslu-/cron þvingunarlokun. root_i er safnað Merkle Tree Hash yfir laufum 0 .. tree_size_i.

16.6 Merkt tréhaus með Arweave Anchor

Arweave akkerisviðskiptin eru undirritað tréhöfuð og skipta út virkjaundirskrift fyrir tréhausinn sjálfan: daglega akkerið þarf engan qub-lykil því Arweave owner er undirskriftin. Moat-kenningin heldur — óbreytanlegt undirlag, ekki qub-geymt leyndarmál, er burðarbært fyrir festu rótina.

Skráningarhönnunin krefst eins heits og árangursríks kvittunarlykils (§16.10), festur í LogProfile og krossundirritaður með anchor_owner. Núverandi útfærsla hefur ekki lokið þeirri traustrótarúthlutun: RECEIPT_SK er valfrjáls, vantar/ógildur lykill gefur sig_b64url: "" og þýdda LogProfile.receipt_pubkey er tómt. Slík kvittun getur lýst viðbættu laufblaði en er ekki óhrekjanleg undirrituð kvittun. Sterkari hönnunarkrafan gildir aðeins eftir að staðfestingaraðili hefur fest samsvarandi opinbera lykilinn og eigandi akkersins undirritar hann. Birtingarsvar án fullkomins kvittunarþyrlis gerir enga skráningarsamþykkiskröfu; sá með tóma undirskrift gerir viðaukastaðsetningarkröfu en enga undirskriftarstaðfestingarkröfu.

SignedTreeHead er kanónískt CBOR (lyklar eftir kóðaðri lengd): size:u64, root:bstr[32], batch:u64, prev:bstr[32] (fyrir sth_hash; genesis = 32 núll bæti), log_id:bstr[32], first_seq:u64, anchored_at:i64. Hash hans er sth_hash = SHA3-256(0x03 || canonical_cbor(SignedTreeHead)).

Festur traustrót. log_id = SHA3-256("QUB_TLOG_V1" || anchor_owner_address). Samrýmanlegur sannreini SKAL krefjast anchor_tx.owner == LogProfile.anchor_owner, þar sem anchor_owner (og opinbera lykillinn fyrir kvittun) er innbyggður í qub_core sem LogProfile — ásamt Quicknet-fastanum sem þegar er í DrandTimelockProvider::quicknet() — og dreift með sannreini-binary-inu. Sannreini SKAL einnig staðfesta Arweave tx gagnatengingu → tx_id sjálfstætt fremur en að treysta á svör frá gjáarsvæði /raw/. Þetta lokar gatinu fyrir falska veski-hliðarlegu villu: „fest á Arweave“ er merkingarlaust þar til sannreini festir hvert veski.

Rúlla er §15 stjórnar viðbót, ekki endurnýting (leyst — §16.15 Q3). §15.2 yfirborðsviðmótsprófíllinn telur nú aðeins upp sig_algs / drand keðjur / umbúðaútgáfur / efni gerðir, og ekki eitt af þessu er í §15.3 viðvörunalistann — LogProfile / anchor_owner er ekki enn í §15 yfirborði. Stjórnun rúllunar verður því að byggja upp: §15.3 er lengd (niðri) til að bæta við LogProfile viðvörunina, og rúlla er undirritaður LogProfile aukabreyting send með sannreini-uppfærslu. Skipulögð rúlla ber kross-undirritun frá út- til inn-göngu; árásar-drifin rúlla getur það ekki (útlykillinn er ótraustur/óaðgengilegur nákvæmlega þá) og fellur aftur á §15-stjórnað aukabreytingu, með fyrri festiforða fork-prófi (niðri) sem takmarkar skaða í millitíðinni.

Tvíræðnigluggi (fyrsta flokks traustbreyta). Lauf er aðeins tvíræðnifarinn þegar umlykur festi hefur verið Arweave-staðfestur. Glugginn er received_at → anchor confirmation (tíðni + Arweave endanleik, án tryggingar um samskipta tafa). Fyrir útgáfu traustrót, veitir núverandi útfærsla starfsemi qub plús hvaða undirskriftarlaus viðbótargögn sem eru til staðar; hún veitir ekki skipulagða óneitanlegheit tryggingu. Þrjú ábyrgðarverkfæri skilgreina fullkláraða hönnun (vitnisgrunnurinn er úrlausn §16.15 Q2):

1. Stimpla kvittun (háð birgðagerð) — SCT-analógurinn sem skilað er þegar viðbótaferill skráar við upphleðslu tekst (§16.10). Hún verður óneitanleg aðeins þegar sig_b64url er ekki tóm og samsvarandi opinber lykil-/festu-eigendra sambandi er fest í sannprófunaraðilanum. Núverandi tóma framleiðsluprófílfesting getur ekki staðið undir þeirri niðurstöðu. Þessi stjórnun á ekki við um útundan kvittunarsamskap eða undirritaða kvittun.

2. Birting fylgjandaferða aðferðafræði + forvera-keðju ganga — festukeðja prev er gengin frá höfði→upphaf; greining (tveir festar á sama size með mismunandi root, eða brotinn prev) er birtingarpróf á misferli. Jafnréttisgreining er tilgreind starfsaðferð, ekki þögul forsendu.

3. Tvíhliða sjálfbirta höfuð — hvert nýtt höfuð {sth_hash, tree_size} er sett inn í sérstakt, qub-eigið opinber, viðbót-þú-þrjár GitHub geymsla (stuðningslegur varnarlegur sjálfbirtur grunnur), með samfélagslegum póst sem bestu tilraun til staðfestingar eingöngu. Misheppnuð setning MÁ senda tilkynningu (ekki að mistakast þögulega). Innleitt (Stig 8) sem publishHead hængur á festu cron (workers/api/src/utils/heads-publish.ts): PUT til innihalds-API án sha er viðbót-þú-þrjár (422 þýðir að höfuðið er þegar birt, aldrei yfirmynt); val- / uppsetningartakmörkuð á PUBLISH_HEAD_GITHUB_{TOKEN,OWNER,REPO} og óvirk þar til geymsla er útveguð. Harðgerð GitHub mistök senda tilkynningu í gegnum health_alert rásina og hækka varanlega bilanastuðul (m:tlog_publish_head_fail); Arweave festan sjálf rennur aldrei aftur á birtingarmistök. „Ekki mistakast þögula“ er tryggt með þeim varanlega stuðli — sem rekstur MÁ hafa borðviðvörun um — jafnvel þó bestu tilrauna tölvupósttilkynning náist ekki. Tvær heiðarlegar takmarkanir stafa af „festu-á-framgangi“ (cron birtir aðeins þegar stærðin stækkar): tímabundin GitHub mistök skilja eftir bil í birtum höfuðröð fyrir þá stærð — takmarkað, ekki þögult (það sendir tilkynningu), og þar sem hvert höfuð staðfestir yfirtrésafn, sannaðir §16.9 samræmisgrunnur brýr bilið; mikilvægt, að sá samræmisgrundur er reiknaður frá yfirvaldagerðri Arweave-festri tréi, ekki frá GitHub yfirborði, þannig að GitHub bil veiklar aldrei sannprófun. Uppfyllingsbæting sem fyllir í birti-hausana-bilið er frestun á endurbótum.

Heiðarleikabundin (bindingartakmörkun). Þar sem qub stjórnar báðum fyrirhuguðum birtingarflötum, er þetta sjálfútgefið, ekki sjálfstætt vottað. Engin vara, markaðssetning eða löglegt yfirborð má halda því fram að skráin sé "sjálfstætt vottað". Eftir að kvittun/prófíll/höfuðhlið hafa verið veitt, er leyfilegt að tvíræðni sé greinanleg og vel undirrituð viðbót skilur eftir sig óumdeilanlega kvittun. Áður en það gerist er sú krafa ekki tiltæk. Sannur óháður þriðji aðili vitni er vísað til framtíðar §15 stjórnarhækkunar.

received_at er staðfest af rekstraraðili og engin krafa má styðjast við hana — hún kemur aldrei fram sem sönnun eða sem staðfesting á neinni vöru / lagalegu / API / sönnunargögnum. Arweave akkerisblokkartíminn T er eina traustlausa tímastimpillinn (efri mörk á "skráð af"). Öll eftirlitsprófun á received_at VERÐUR að bera saman við T, ekki við anchored_at STH reitinn sem rekstraraðilinn stjórnar; slík athugun er aðeins vörn gegn heiðarlegum klukkuvillum rekstraraðila, ekki ábyrgðarstýring gegn illgjörnum rekstraraðila (§16.15 Q5).

16.7 Viðskiptaform og hraði akkerisviðskipta

AnchorBundle er kanónískur CBOR Arweave viðskiptalíkaminn, skrifaður með §16.8 pakkanum: ver:u8, sth:bstr (kanónísk SignedTreeHead bæti), prev_anchor:bstr (hráar bæti fyrir akkeri tx auðkenni; sleppt við upphaf), chain_hash:tstr (DRAND-keðjan í gildi — quicknet), og lotu-lauf-CBOR straumurinn í seq röð svo akkerið sé sjálfbært: eftirlitsmaður endurleiðir root úr líkamanum án qub háðs. (Ef laufstraumurinn verður stór við mikinn umfang getur framtíðar endurskoðun aðeins skuldbundið laufbil með tilvísun; tekið eftir, ekki tekið upp í v1.)

Arweave-merki eru viljandi teljanleg — logginn er ætlaður til að finnast, ólíkt einkaspurningum: App-Name: qub-tlog, Anchor-Format: 1, Log-Id: <hex>, Batch: <n>, Tree-Size: <n>, Root: <hex>, Prev-Anchor: <tx>, Content-Type: application/cbor. Merkin eru óáreiðanlegar vísbendingar; CBOR-stofnunin er eini valdhafinn.

Taktur: daglega sjálfgefið, endurskoðað með magni (stærðar-örvun styttir sjálfkrafa áhrifatakt undir álagi). Núverandi framleiðandi innleiðir ekki borgaða-segl-kraft-ankur krók. Ankur-veskið er sérhæft og hægvirkt, aðskilið frá hlaða-veskinu — það VERÐUR að vera sitt eigin JWK (aðgreind lykill, ekki rökrétt hlutverk á hlaða-veskinu) svo að brot á hlaða-veskinu geti ekki falsað ankra — með harðri daglegri takmörkun á ankur-viðskiptum. Geymsluhátturinn er skýr: mjög þröngt heitt lykil með strangri öryggislokun og lágan stöðulíðan, ekki „kalt“ — veski sem sjálfkrafa undirritar daglega getur ekki verið kalt, og forskriftin gefur það ekki í skyn.

16.8 ANS-104 Pakki

Innanhúss ANS-104 DataItem kóðari og djúphash undirritari, um 300 línur, aðeins Web Crypto, engin npm háð (bæði Turbo SDK fylgja ekki npm ci --ignore-scripts framboðskeðjugáttinni). DataItem bita uppsetning:

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

Undirritun er Arweave deepHash — endurkvæm SHA-384 útdráttur (kröfur Arweave fyrir gagnaflutning, crypto.subtle.digest("SHA-384")) yfir ["dataitem", "1", sig_type, owner, target, anchor, encoded_tags, data] — svo RSA-PSS yfir djúphash með veski JWK í gegnum crypto.subtle; id = base64url(SHA-256(signature)). SHA-384 hér er einangruð sem aðeins Arweave-gagnaflutningslíkön, aldrei qub-trust líkan (§15 skráir girðingu; qub-trust hash er SHA3-256 um alla vegu).

ANS-104 kóðaleiðin þjónaði seinkanlega bakfalla/tæmingu vélbúnaðar og skrifar AnchorBundle DataItems. Venjuleg útgáfu leið býr fyrst til nákvæma undirritaða Arweave viðskipti og heldur JSON í endingargóðri útsendingarbox; bein birting er biðtímasamsetning, og tóm-path reynir sömu viðskipti áður en það beitir bundler bakfallinu. Undirritunarkerfi (leyst — §16.15 Q8): v1 undirritar með RSA-PSS (undirritunargerð 1) endurnýtir núverandi Arweave veski JWK aðferð (engin ný langtíma lykilgeymsla, styður „einni færri leynd“ kenningu); Ed25519 er seinkanlegt til §15 PQ-flytjunar leiðar.

Handsmíðaður djúphash er hættulegasta, lægst-náttúrulega þekktu kóðann í W5, svo lokun hans er ekki samningsatriði (§16.15 Q8):

1. Þvermálsprófunin tlog_v1.json (Rust + TS, §14.5 wrapper_v1.json mynstrið) nær yfir deep-hash, DataItem bita + auðkenni, lauf-hash, 5-lauf rót + endurskoðunarslóð, STH hash, proof um þátttöku og proof um samkvæmni — í bæði undirritun og staðfestingar átt (staðfestingar áttin skiptir máli því §16.6 staðbundinn tx → tx_id athugun dregur deep hash inn í hverja sjálfstæðu staðfestara, ekki bara skrifarann).
2. Eitt skipti samverkunarpakki í gegnum tilvísunar ANS-104 bundler, neytt sem einni föstum prófunargögnum — aldrei npm keyrsluframleiðsluþáttur (Web-Crypto-eina / engar install-skrár standa).
3. Deep-hash + RSA-PSS leiðin verður að fara um sömu crypto.subtle frumefni sem framleiðsla notar, svo innanhúss kóðarinn sé bitasamhæfur.
4. Stöðugt eftirlit eftir pakka samþykkt staðfestir að hver anchor / fallback DataItem nær raunverulega Arweave samþykkt, með viðvörun + rofhring — því deep hash þjónar einnig Arweave-tæmandi fallback biðröðinni, þannig að hljóðlát afturför myndi fylla þann röð með neti hökkuðum hlutum á nákvæmlega því bilunartímabili sem hún á að hylja.

16.9 Inntektar- og Samkvæmnisprófanir

Bæði eru RFC 9162, SHA3-256, þjónað sem kanónískt CBOR.

InclusionProof — GET /api/v1/qub/:tx_id/proof: ver:u8, leaf:bstr (nákvæm lauf CBOR — staðfestarinn endurreiknar leaf_hash sjálfur og treystir aldrei gefnum 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. Ein skýr og ótvíræð lyklalisti, festur með prófun vigur.

Sjálfstæð staðfesting (enginn qub server, útvíkkar §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).

Sönnunargeymsla VERÐUR að vera með hnitalykil (leyst — §16.15 Q7, blokkunarskilyrði). Kaldlaufa sönnunarframleiðsla er réttmætishlutlaus aðeins ef R2 endurskoðunarefnið er varanlegt Merkle-hnút geymsla sem er lykilsett af algjörum tréhnitum (level, index) — ekki á batch hnútadelta. Með hnitalykilgeymslu er hver (leaf i, size N) endurskoðunarleið safn O(log N) beint R2 GET með enga endurútreikning yfir lotumörk; með lotulyklageymslu er hún það ekki, sem er geymslu- og skipulagsbilið sem þessi upplausn lokar. Laufhlutarnir eru einnig efnistengdir með seq. W5 prófunarvektor VERÐUR að sanna genesis-tímabils kalt lauf gegn mun síðari rót með því að nota aðeins R2 + Arweave með LogDO geymslunni hreinsað, svo fullyrðingin um endurheimt öryggis í §16.13 er studd frekar en staðfest. O(log N) raðbundin R2 GET tilheyra aðeins á ósamstilltu sönnunarendapunktinum — aldrei á þéttingarheita leiðinni (§16.10) eða á hvern tick cron.

16.10 R2-First Ack pöntun

Útfærða POST /api/v1/upload röðin er:

1. Framhliðarhlið (auðkenning, staðfesting, idempotency shard-lykill) — óbreytt.
2. Búðu til, merkja og undirrita nákvæmlega einstaka Arweave færslu. Þetta leiðir tx_id staðbundið, þó að færslugerð geti sótt umbunar-/akkerisgögn frá hlið. Undirbúningsmistök mistakast samt beiðnin áður en staðfesting berst.
3. Samstillt skrifa valinn grip á qub-cache/<tx_id> og viðhalda stöðugum sköpunar-aðgerðum/útkassaskrám. Þetta eru endingar- og endurprófunargrunnur; mistök fyrir uppgjör skila 503.
4. Þegar LOG_DO er stillt, reynir samstillt LogDO.append(leaf). Einn ritari úthlutar seq, lengir innkomukeðjuna og uppfærir framlínuna. Viðaukandi RPC gerir aðeins það; lotulokun keyrir utan leiðar á viðvöruninni. Viðaukaflutnings-/forritsbilun er núna fail-soft: svarið getur samt tekist án log_seq, receipt eða anchor_status. Þrátt fyrir athugasemd um útfærslu er engin sjálfvirk samræming síðar skráningar tengd í dag.
5. Skilaðu staðfestingu. Settu { log_seq, anchor_status: "pending", receipt } aðeins inn þegar viðbótin skilaði fullkomnu og árangursríku töppunni. receipt.sig_b64url er tómt þegar kvittunarundirritarinn er ekki tiltækur; viðskiptavinir mega EKKI kalla það gildi undirritað eða óhrekjanlegt. Fjarvera túðunnar þýðir aðeins varanlega birtingu, ekki samþykki gagnsæisskráar.
6. Notaðu eitt frestað verkefni til að birta nákvæmlega undirritaða færslu. Árangur fjarlægir úthólfið; misheppnað kerfi skilur það eftir fyrir takmarkaða dren-krónið og má ekki breyta þegar staðfestu tx_id. Bráðabirgðalýsigögn og aðrar bestu tilraunir hliðarvagna eru einnig frestað.

Töfamörk. Beiðnileiðin inniheldur framhliðarverkefni/kvótavinnu, undirbúning/undirritun viðskipta, varanlegar R2-skrif og (þegar stillt) LogDO tilraun. < 300 ms birtist í hönnunarskoðun sem rekstrarmarkmið, ekki sem trygging fyrir samskiptareglum; núverandi undirbúningsskref viðskipta getur framkvæmt beiðni um lýsigögn um hlið. Töfarviðvaranir og ræsingarhlið eru rekstrarstýringar, ekki sönnunargögn sem staðfestingaraðili hefur aðgang að.

16.11 Traustlíkanið — nákvæm fullyrðing, skilgreind eftir lauftegund

Fyrir kind=0x01 (staðfest): *"Þetta efni — líkamspörun body_hash, auðkennt af qub_id — var fest í viðaukaskrá qub á staðsetningu seq og var til ekki síðar en Arweave blokkartími T; það var dulritunarlega ólæsilegt þar til drand umferð R = unlock_round(unlock_at)." * Þetta er full {tlock round binding + Merkle inclusion + anchored root} þreföldun.

Fyrir kind=0x02 (staðfest, sjálfgefið): *"Ógegnsæur dulmálstexti með innihaldsvistfangi chash, sem fullyrðir qub_id og unlock_at, var festur í viðauka-einungis logginn á stöðu seq og var til ekki síðar en Arweave blokkartími T." * Hringlaga og líkamsfætur eru veittar af núverandi §11 .qub-pakka staðfestingu (qub_core::unlock), ekki af loginu; það sem loggið bætir við yfir beran hver-qub færslu er óbreytt röðun, traustlaus efri skuldbindingartími og óvissuviðnám.

Báðar kröfurnar útiloka, samkvæmt §11: höfundarrétt án sig_alg ≥ 0x01, ásetnings og tímasetningar fyrir undirakkeri. Hvorki leyfir neinum kröfum að byggja á received_at.

Kröfuþak (bindandi ræsingartakmörkun — leyst §16.15 Q1). Fyrir fullyrt (kind=0x02) lauf er umfangskrafan hér að ofan þak á því sem hvaða vara, markaðssetning, skilmálar eða sönnunaryfirborð má fullyrða. Enginn flötur má segja eða gefa í skyn að logginn sanni innihaldið eða opnunarhring bitablindrar hleðslu — loggið sannar röðun + traustlausan efri bundinn skuldbindingartíma ógegnsæs dulritaðs texta. Innihald og umferðarsönnun koma eingöngu frá núverandi §11 .qub-pakka staðfestingu, sem er óháð loggi. Útgáfa án árangursríkrar viðauka/móttöku hefur enga skráningarkröfu yfirhöfuð.

16.12 Útgáfustýring og W3 samhæfing

Það er engin SealedQub vírahnútur og því engin bump á samskiptaregluútgáfunni (§12.2): loggið er hliðarbíll sem bindur sig við núverandi reiti og bæti, svo það fer ekki inn í §12.3 sögu samskiptareglunnar. Valfrjáls drand_chain_version W3 er óbreytt og er eina valfrjálsa SealedQub reiturinn. Loggið kynnir í staðinn sín eigin sjálfstæðu útgáfurými — LOG_VERSION_1, ANCHOR_FORMAT_1, InclusionProof.ver — sem endurspeglar §12.5 sjálfstæði umbúðarútgáfu (umbúðin ber útgáfubita óháð samskiptaregluútgáfunni og loggútgáfurnar fylgja sömu aðskilnaði).

Afhending sönnunar er sótt sjálfgefið, með valfrjálsri meðfylgni. Sönnun getur ekki verið til við innsigli (akkerið hefur ekki verið skrifað enn), svo innsiglunartímapakkinn .qub helst sönnunarlaus. Sannprófari W7 sækir GET …/proof einu sinni, eða endurbyggir sönnunina úr opinberu AnchorBundle með Arweave-fyrirspurn á Log-Id. .qub pakkinn (W7) áskilur valfrjálsum inclusion_proof meðlimi — sem vantar við innsigli, fyllt með endurútflutningi eftir akkerið fyrir kalda geymslu — eftir sama "valfrjálsa, sjálfgefna sleppt, samlaga" mynstri og drand_chain_version W3.

16.13 Varðveisla

Varðveislugluggar fyrir LogDO opna hala, R2 sönnunarundirlagið, akkerisrofa teljara og bundlara fallback-biðröðina eru tilgreindir í docs/DATA-RETENTION.md. Meginregla: heita geymsla loggsins (LogDO) er endurheimtanleg eftir akkeri; endurskoðunarefni þess — hnitalykilinn (level, index) Merkle-hnútageymslan + seq-adressuðu laufhlutirnir (§16.9) + Arweave festingarnar — er varanleg. Endurheimt kalds laufs frá DO gerir aldrei útgefna sönnun ógilda, því sönnun leysist gegn þeim varanlega R2 hnútageymslu og Arweave akkerinu, ekki DO (og §16.9 þurrkaða DO prófunarvektorinn sanna það).

16.14 Prófunarvektorar

W5 sendir þvermála festingu tlog_v1.json (§16.8) auk unninna vigra: kind=0x01 og kind=0x02 laufblað → leaf_hash; 5-laufa safnrót; eitt innfellingarsönnun; eitt samkvæmnispróf; eitt AnchorBundle; og eitt DataItem auðkenni. Þessar eru samhliða §14.5 ytri umbúðarvigrum og eru notaðar bæði af Rust (qub-core) og TypeScript (Worker) útfærslunum.

16.15 Endurskoðunarákvarðanir (W5 — leyst)

Ytri endurskoðun W5 (andstæð hönnunarpassi + undirskrift eiganda) er lokið. Hver ákvörðun hér að neðan er tekin upp og endurspeglast í §16 textanum hér að ofan; bindandi ræsingartakmarkanir eru endurteknar í lokin. Innleiðing getur farið fram undir þeim.

1. Sjálfgefin slóð (kind=0x02) lauf heiðarleiki — LEYST. Sendu tví-laufa skiptingu eins og tilgreint er: kind=0x02 samþykkir hvorki body_hash né drand_round. Enginn *_body_hash reitur á bætablinda slóðinni (það væri læsilegasta falska "staðfesta" merkið fyrir samþættara og er þægindi sem §11 veitir þegar frá pakkanum). Ekki **krefjast netþjóns-innsiglis fyrir logvottaðar leitarniðurstöður (sem myndu þvinga hreinan texta í gegnum Worker og eyðileggja dulritunarskurðinn). Allur sjálflýsandi skammhlaup á heima í .qub pakka / sönnunarumslagi sem staðfestingarendurreiknað svið, aldrei laufreit. Eigandastaðfest kröfutakmark: §16.11.

2. Ábyrgð á óvissu / vanrækslu — HÖNNUN LEYST, ÚTHLUTUN ÓFULLKOMIN. Hönnunin krefst þess að innsigliskvittunarlykillinn sé festur í LogProfile og krossundirritaður af anchor_owner, auk eftirlitsaðferðafræði, fyrri keðjugöngu og tvöfalt sjálfbirt höfuð. Þýdd prófíl og dreifingarkrókar eru enn staðgengils/valfrjáls eins og útskýrt er í §16.6, svo sterkari greinanleg + móttekin krafa er ekki gild fyrr en þessar hlið lokast. Hún má aldrei markaðssetja sem sjálfstætt vitnað. Sannur þriðji aðili vitni er vísað til §15 stjórnunarhækkunar.

3. Fest traustrót eiganda akkeriseiganda + snúningur — LEYST. Taktu upp LogProfile pinna (§16.6); sannprófarinn athugar anchor_tx.owner == anchor_owner og staðfestir viðbragðsgögnin → tx_id bindingu staðbundið. Snúningsstjórnun er §15 viðbót við byggingu (§15.3 trigger bætt við), ekki endurnýting; skipulagðar snúningar krossmerkja, málamiðlunardrifnar snúningar falla aftur á §15 bump með fork check sem takmarkar skemmdir.

4. Einka-qub blöðublindun — LEYST. Haltu blindingu fyrir einkaqub (ref = SHA3-256(qub_id ‖ log_blind_secret)), hrá qub_id fyrir opinberar qubs (þegar §16.2.1), chash sem sjálfstæð jafntefli. log_blind_secret er fylgni-/Sybil-gæðaleyndarmál, aðeins snúið fram (§16.2.1).

5. received_at — LEYST. Haltu því í laufinu, skuldbundið en skýrt ósönnunarhæft; aldrei komið fram sem sönnun eða ágreiningur um staðfestingu á neinu yfirborði. Öll skynsemispróf eftirlits bera saman við Arweave blokkartímann T, ekki við anchored_at sem rekstraraðilinn stjórnar (§16.6).

6. Stigskipt sönnunartímasetning — HÖNNUNARLAUSN, EKKI NÚVERANDI LEIÐIR. Endurskoðuð hönnun úthlutar festiblokkatíma til lotulaga stigsins og nákvæmri klukkustundarprófun til greidds T3, án tölulegs SLA fyrir þá fyrrnefndu. Núverandi leiðir hafa ekki tengt þann viðskiptalega aðgreiningu: þær skipuleggja einstaka færslu fyrir hverja samþykkta útgáfu og skráningarþekja helst skilyrt eins og fram kemur í §16.1/§16.10. Vöruafrit verður að lýsa útfærslunni, ekki þessari framtíðar stigaskiptingu.

7. Samantekið tré yfir Verkamenn — LEYST. Eitt samantekið RFC 9162 tré + frontier-cached single-writer LogDO (þægilegt svigrúm miðað við ~1k skrif á sekúndu DO þak; fresta Merkle-of-shard-roots skiplagi þar til nálægt því). Koordinata-lykla (level, index) R2 hnútageymsla + þróað DO kaldlauf prufuvektor eru innleidd (§16.9). < 300 ms er enn hönnunar/rekstrarmarkmið, ekki samskiptaloforð (§16.10).

8. ANS-104 undirskriftarskema + djúp-hash — LEYST. RSA-PSS (undirskriftargerð 1, endurnýtt sérstakt anchor-wallet JWK); Ed25519 frestað til §15 PQ leiðarinnar. Handgerða SHA-384 djúp-hash er háð both-directions cross-impl fixture, statískri einungis reference-bundler samskiptaprófun, sameiginlega crypto.subtle ferli fram og aftur, og Arweave-viðurkenningar eftirliti eftir pakka (§16.8).

Bindandi útgáfuþröskuldar (bera inn í útfærslu + vöru/lögfræðilega yfirferð):

• Krafaþak (Q1/Q6). Enginn flötur má segja færsla skráarinnar sönnur innihald tiltekinna laufblaða eða opnunartíma; heimilaður krafa fyrir vel fest kind=0x02 laufblað er pöntuð, með vísbendingu um hrekkjanleika, með traustlausri efra-mörk skuldbindingartíma. Svar án kvittunar tvíundar hefur enga skráarkröfu. Engin tímapunktakópi ber með sér tölulegar töfargildingar.
• Heiðarleiki vitna (Q2). Markaðshnykkur sem greinanlegur + kvittaður, aldrei sjálfstætt vitnað.
• Kvittun + festilyklarnir (Q2/Q8). Áður en kröfur um ekki-neitun/festingu-eftirlit eru sendar skuli útvega og samsetja kvittunar almennan lykil, undirrita hann með útvegaða festueigandanum, og halda festungarpokanum sem sitt eigið JWK aðskilið frá hlaða-pokanum.
• Djúpnáms gátt (Q8). Enginn festing eða T3 viðskipti fara af stað þar til tvíkvæða prófun + samvirkni athugun gengur; samþykki eftirlitskerfisins vekur viðvörun ef hún mistekst.
• Skilyrði fyrir geymslu (Q7). Samstilltur lykilstjórnaður hnútageymsla + hreinsaður DO kuldahlutur eru forsendur fyrir „endurheimt ógildar aldrei sönnun“ trygginguna.

17. Færanlegur staðfestingarpakki (.qub)

Staða. Þessi hluti er útfærður (W7 / UP-C2): qub_core::export býr til og þáttar pakkann og tools/qub-verify er opinbert, sjálfstætt skipanalínuverkfæri sem staðfestir hann án nettengingar. §11 og §16.9 vísa þegar til „.qub pakkans“ sem einingarinnar sem sjálfstæður staðfestir notar; þessi hluti skilgreinir bæti hans og staðfestingarferlið. Þetta er eingöngu viðbót — pakkinn safnar saman fyrirliggjandi ílagi §11 og breytir engu þráðarsniði á keðju.

17.1 Tilgangur

§11 staðfestir að hvaða þriðji aðili sem er geti sannreynt dulfræðigrip qub án aðstoðar qub. .qub pakkinn gerir sannprófunina færanlega og ótengda: hann safnar innsigluðu CBOR-bætunum og drand-umferðarundirskriftinni sem aflæsir þeim í einn sjálfstæðan grip, svo viðtakandi geti sannreynt heilleika efnis, bindingu umferðar og mögulegar höfundarundirskriftir án nokkurs netkalls (engin geymslusókn, engin virk drand-beiðni, ekkert qub API). Pakkinn einn og sér sannar ekki hvenær dulkóðunartextinn var búinn til; óháð sannreynd geymslufærsla eða akkeruð annálssönnun veitir þessa aðskildu fullyrðingu um tilvistartíma (§11, §17.5).

17.2 Pakkasnið

QubBundle er handskrifað kanónískt CBOR samkvæmt sniðinu í §3.1 (ákveðnar lengdir, engin merki, engar fleytitölur, stysta heiltölusnið, NFC-texti, valfrjálsum reitum sleppt þegar þeir eru fjarverandi og lyklar raðaðir eftir hækkandi lengd kóðaðra bæta og síðan bætaröð). Þrír 15 stafa lyklarnir raðast d < i < s. Hrá .qub skrá er nákvæmlega þessi bæti; fyrir URL eða afritun og límingu eru sömu bæti base64url(no-pad).

drand_round og drand_chain_id eru þægindavarpanir úr sealed_qub_cbor, geymdar svo verkfæri geti lesið þær án þáttunar á innri CBOR. Þær eru leiddar við smíði og endursannreyndar við afkóðun gagnvart þáttaða innsiglaða qub-num; pakka er hafnað ef efsta stigs reitur stangast á við burð hans. Kóðunaragi speglar annað þráðarsnið: hafna skal tómri drand_signature eða arweave_tx_id og setja mörk á alla reiti af breytilegri lengd.

17.3 Það sem innbyggða drand-undirskriftin sannar

Pakkinn geymir drand-undirskriftina í stað þess að staðfestir þurfi að sækja hana. Tímalásafkóðun (tlock yfir drand-keðjunni, §8) getur aðeins tekist með ósviknu vitaundirskriftinni fyrir bundnu umferðina—gildi sem keðjan birtir fyrst þegar umferðinni lýkur og sem er gild BLS-undirskrift undir dreifilykli keðjunnar. Fölsuð eða röng undirskrift stenst ekki BLS-sannprófun eða IBE/AEAD-afkóðun. Pakki sem tekst að afkóða sannar því: dulkóðunartextinn er bundinn við umferð R og umferð R er liðin. Staðfestirinn festir keðjuna (DrandTimelockProvider::quicknet()) og framkvæmir umferðarbindingarathugun §11, svo pakki getur ekki staðhæft umferð sem dulkóðunartextinn er ekki bundinn við.

Þetta er sönnun á útgáfuskilyrði, ekki tímastimpill sköpunar. Eftir að umferð R er liðin getur hver sem er búið til nýjan dulkóðunartexta fyrir R og pakkað honum með undirskriftinni sem þá er þegar opinber. Því MÁ EKKI lýsa pakkanum einum og sér sem sönnun þess að dulkóðunartextinn eða efnið hafi verið til fyrir R, fyrir unlock_at eða fyrir nokkurn atburð.

17.4 Ótengt staðfestingarferli

qub-verify <file.qub> keyrir staðlaða ferlið í §11 alfarið úr pakkanum og knýr qub_core::unlock::unlock með festum DrandTimelockProvider:

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.

Skipanalínuverkfærið skilar lokakóðanum 0 (staðfest), 1 (staðfesting mistókst — enn læst, líkamatæti passar ekki, binding umferðar/keðju rofin eða undirskrift stenst ekki sannprófun) eða 2 (röng notkun / gallaður pakki). --json skýrsla ber sömu niðurstöður til sjálfvirkni. Þar sem pakkinn er sjálfstæður eru staðfestingarsafnið (qub-core) og skipanalínuverkfærið (qub-verify) eini hugbúnaðurinn sem þriðji aðili þarf; bæði eru opinber og endurnýta fyrirliggjandi staðfestingarleið samskiptareglunnar — engin sérsmíðuð dulritun.

17.5 Tengsl við gagnsæisannálinn

inclusion_proof er valfrjáls reitur fyrir Merkle-innifalningarsönnun §16. Staðfesting pakkans eins (§17.4) er fullnægjandi fyrir heilleika, bindingu/lok umferðar og valfrjálsa höfundarsönnun, en hefur viljandi enga óháða tímastimplaða fullyrðingu um tilvist. Útfyllt og fullsannreynd akkeruð inclusion_proof bætir við laufgerðarháðu skuldbindingunni og efri tímamörkunum úr §16.11 án þess að breyta útgáfu pakkasniðsins. Fjarverandi sönnun merkir aðeins „engin sönnun innifalin“—ekki „ógild“ og ekki endilega „ekki akkeruð“.

Í viðmiðunarútfærslunni er reiturinn nú gerðaður: qub_core::export::QubBundle::inclusion_proof_typed() skilar Option<InclusionProof> sem ber allt §16.9-sniðið (lauf, endurskoðunarslóð, akkeruð rót og AnchorRef) í sama ógegnsæja CBOR-reitnum — án hækkunar á útgáfu pakkasniðs. Sjálfstæða qub-verify skipanalínuverkfærið notar hann með --anchor leið sinni og — þar til akkerisveskið er útbúið (§16, Staða) — tilkynnir sönnun með innfylltum staðgengilseiganda sem aðeins innifalningu fremur en að hún sé að fullu akkerissannreynd.