qub Protokol Spesifikasyonu

qub, kriptografik zamansal taahhütler için bir protokoldür: kelimeleri gelecekteki bir tarihe mühürlemek ve daha sonra tam olarak neyin mühürlendiğini doğrulamak için bir sistemdir; bu, drand tarafından turlu bir şekilde serbest bırakılmasını sağlar ve—bir depolama işlemi veya şeffaflık günlüğü kanıtı mevcut olduğunda—şifre metninin ne zaman taahhüt edildiğine dair bağımsız olarak zaman damgalanmış bir üst sınır sunar.

Üç temel öğe bunu çalıştırır. drand merkezi olmayan bir rastgelelik işaretçisidir—açığa çıkış tarihi, qub'un iyiliğiyle değil, kriptografik olarak uygulanır. Dayanıklı depolama geçerli yayın yolları bireysel kalıcı depolama işlemlerini planlarken, onaylanmış mühürlü baytları korur; başarılı genel yükleme günlük eklemeleri ayrıca toplu, sabitlenmiş taahhütlere katılabilir. ML-DSA-65 post-kantum bir dijital imzadır—yazarlık etkinleştirildiğinde, qub yazarın cihazından hiç çıkmayan bir sır içeren bir anahtar çiftiyle ilişkilendirilir.

Birlikte bu ilkel öğeler, zaman kilitli ve müdahaleye karşı kanıtlı, isteğe bağlı olarak atanabilir ve bağımsız olarak zaman damgalanabilir bir ifade oluşturur — değeri, dünyanın geçmişi üretme yeteneği geliştikçe artan bir makbuz.

Bu belgenin geri kalanı, birlikte çalışabilir uygulamalar için gerekli olan normatif spesifikasyondur.

qub Protokol Spesifikasyonu

Bu belge, qub zamanlı taahhüt sistemi için normatif protokol spesifikasyonudur. Birlikte çalışabilir uygulamalar için gerekli olan veri yapılarını, serileştirme kurallarını, türetme formüllerini ve doğrulama prosedürlerini tanımlar.

Kapsam: protokol katmanı kasıtlı olarak dilden bağımsızdır — qub gövdesi opak düz metin / markdown / pakt baytlarıdır ve yerel ayarlara duyarlı sunum izleyicinin sorumluluğundadır (qub.social web uygulaması, <qub-embed> iframe'i, MCP istemcileri, vb.).

1. Gösterim ve sözleşmeler

Ön görüntü yapılarındaki tüm tam sayılar, aksi belirtilmedikçe big-endian sabit genişlikli bayt dizileri olarak kodlanır (i64 → 8 bayt, u8 → 1 bayt).

Tüm zaman damgaları UTC cinsinden Unix saniyeleridir.

2. Veri yapıları

2.1 ComposeQub (Yaratıcının bellek içi durumu)

CBOR'a serileştirilmez. Kalıcı depolamada saklanmaz. Yaratıcı uygulamasına yereldir.

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 (Şifresi çözülmüş yük)

Kanonik CBOR (§3) kullanılarak serileştirilir. SealedQub içinde şifrelenir. Bu, şifre çözüldükten sonra içerik bütünlüğünü kanıtlayan yapıdır.

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
}

Temel (imzasız metin qub): version = 0x01, content_type = 0x01, sig_alg = 0x00; imza ve kefil alanları eksiktir. Diğer isteğe bağlı meta veri alanları mevcut olabilir.

Diğer v1 yapılandırmaları: content_type = 0x03 (pakt gövdesi, bkz. §6.1); author_signature ve author_pubkey mevcut olarak sig_alg = 0x01 (ML-DSA-65) (bkz. §9.3); birlikte imzalanan paktlar için cosigner_pubkey ve cosigner_signature birlikte mevcut (bkz. §9.7); yanıt zinciri qub'ları için reply_to, üst qub'un qub_id'sine ayarlanır (imza kapsamı sonuçları için bkz. §9.3).

2.3 SealedQub (Kanonik aktarım biçimi)

Kanonik CBOR (§3) kullanılarak serileştirilir. Bu iç tel artefaktıdır: kamu teslimatı bu baytları çıplak saklarken, özel teslimat onları sarar. OuterWrapper depolamadan önce (§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 (İzleyici uygulama durumu)

CBOR'a serileştirilmez. İzleyici uygulamasına yereldir. Başarılı şifre çözme ve doğrulamadan sonra inşa edilir.

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. Kanonik CBOR profili

Tüm SealedQub ve QubEnvelope serileştirme bu profille uyumlu OLMALIDIR. Aynı mantıksal yapı verildiğinde iki uygulama aynı baytları üretmek ZORUNDADIR.

3.1 Kodlama kuralları

3.2 Doğrulanmış kanonik anahtar sıraları

Bu anahtar sıraları normatiftir. Uygulamalar anahtarları tam olarak bu sırayla yaymak ZORUNDADIR. Hata ayıklama onaylamaları, üretim dışı yapılarda sıralamayı doğrulamalıdır (SHOULD).

QubEnvelope (sürüm 0x01, imzasız, tüm isteğe bağlı alanlar yok):

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

QubEnvelope anahtar sırası türetmesi: her anahtar bir CBOR metin dizesidir. Kodlanmış uzunluk = 1 baytlık başlık + dize uzunluğu (24 bayttan kısa dizeler için). Önce toplam kodlanmış uzunluğa göre, aynı uzunluktaki anahtarlar için sözlüksel olarak sıralayın.

SealedQub (sürüm 0x01, herkese açık, alıcı yok):

"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 (pakt gövdesi, content_type 0x03):

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

PactTerm (terms dizisinin satırı):

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

PartyIdentifier (party_a / party_b haritası):

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

3.3 Bayt kodlama referansı

4. Normatif türetmeler

4.1 qub_id

qub_id, bir qub'u benzersiz şekilde tanımlar ve QubEnvelope'u SealedQub'a bağlar. Zarf içeriğinden deterministik olarak türetilir.

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

Etki alanı ayırıcı kodlaması: "QUB_ID_V2" dizesi 9 ASCII bayttır. Hizalama için 10 bayta ulaşmak amacıyla tek bir 0x00 dolgu baytı eklenir. Uygulamalar tam olarak bu 10 baytı kullanmak ZORUNDADIR: [0x51, 0x55, 0x42, 0x5F, 0x49, 0x44, 0x5F, 0x56, 0x32, 0x00].

outcome_at kodlama: Bir ön sürüm uygulama revizyonu, isteğe bağlı olanı katlamak için öngörü uzunluğunu 92 bayttan 100 bayta uzattı outcome_at alanı bağına. Yok outcome_at 8 sıfır bayt olarak kodlanır; protokol doğrulayıcıları reddeder outcome_at <= 0 her yerde böylece bu nöbetçi geçerli bir değerle çarpışamaz. Bkz. §3.2 (kablo formatı) ve ağaç içi tasks/verdict-uplift-plan.md bu alanı motive eden karar mekanizması için.

drand_round kodlama: Daha sonraki bir ön sürüm uygulama revizyonu, katlamak için ön resmi 100 bayttan 108 bayta çıkardı drand_round (hedef drand turu, §4.3) bağlamına ve alan ayırıcısını yükseltti QUB_ID_V2. Bu, timelock turunu qub kimliğine bağlar: bir ağ geçidi, şifre metnini gösterilen turdan farklı (örneğin, zaten geçmiş) bir tura yeniden bağlayamaz unlock_at ima eder. Kilit açma prosedürü (§8) ayrıca tlock şifre metni stanzasına yerleştirilen turun eşleşip eşleşmediğini doğrular unlock_round(unlock_at), böylece gösterilen kilit açma zamanı, şifre çözmeyi tetikleyen tur olduğu kanıtlanabilir.

Özellikler:

• Ön görüntüye bağlı herhangi bir alanı değiştirmek—version, content_type, created_at, unlock_at, outcome_at, drand_round, ham body baytlar (aracılığıyla body_hash), veya title (aracılığıyla title_hash)—farklı bir şey üretir qub_id.
• Qub_id şifrelemeden önce hesaplanır. Hem QubEnvelope hem de SealedQub aynı qub_id'yi taşır. Görüntüleyici, şifre çözme işleminden sonra eşleşip eşleşmediklerini doğrular.
• qub_id bağlı değildir sender_label, reply_to, imza baytları veya imzalama açık anahtarları. Ancak mevcut V2 imzalama yapısında, sender_label ve reply_to doğrudan doğrulanır sender_label_hash ve reply_to_or_zero (§9.3) imzalar mevcut olduğunda.
• Mühürlü Qub'u Değiştirmek title (her şey düzeltildikten sonra) değişiklikler qub_id aracılığıyla title_hash. Bu nedenle bir ağ geçidi, qub kimliğini geçersiz kılmadan geri sayımda görüntülenen düz metin başlığı değiştiremez.
• Mühürlü Qub'u Değiştirmek outcome_at (her şey düzeltildikten sonra) değişiklikler qub_id ön görüntü aracılığıyla. Bir ağ geçidi, qub kimliğini geçersiz kılmadan geri açıklama öncesi geri sayımda gösterilen kararı değiştiremez.
• Değişiyor drand_round (her şey düzeltildikten sonra) değişiklikler qub_id ön görüntü aracılığıyla. Bir geçit, qub kimliğini geçersiz kılmadan timelock şifresini farklı bir tura yeniden bağlayamaz; §8 kilit açma zamanı stanza-tur kontrolü ile birleştirildiğinde, görüntülenen unlock_at asıl olarak şifre çözmeyi kontrol eden turdur.

4.2 body_hash

body_hash = SHA3-256(body)

Burada body, ham Vec<u8> içerik yüküdür. Metin qub'ları için bu, UTF-8 kodlamalı qub gövdesidir.

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

Burada title, açıklama öncesinde izleyici geri sayımında gösterilen isteğe bağlı düz metin başlığıdır (bkz. §3.2). NFC normalleştirme, özetin görsel olarak eşdeğer kod-nokta dizileri arasında kararlı olması için özet zamanında çalışır. Tümü sıfır olan işaretçi, yok durumu için ayrılmıştır; boş bir dize, kanonik CBOR sınırında "yok"un kanonik olmayan kodlaması olarak reddedilir (kanonik kodlama alanı tamamen çıkarır).

4.3 Kilit-Aşama Haritalaması

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

Bu, referans tlock eşlemesidir (drand'in CurrentRound). drand tur yayımlar N de/da chain_genesis_time + (N - 1) * chain_period_seconds, böylece formül seçer yuvarlak akımda unlock_at — bir izleyicinin geldiği sırada imzası ilk olan tur unlock_at kullanabilir.

Hizalama özelliği (pratikte önemli olan durum): ne zaman (unlock_at - chain_genesis_time) tam bölünebilir chain_period_seconds, seçilen turun imzası yayınlanır tam olarak unlock_at, daha önce hiç. Bu her zaman referans dağıtımı için geçerlidir: quicknet'in başlangıç zamanı (1692803367) 3 saniyelik periyoduna bölünebilir ve referans uygulamalar pin kilit açma sürelerini tam dakikalara sabitler. Hizalanmamış bir unlock_at, seçilen turun imzası, bir dönemden daha kısa bir süre önce yayınlanır unlock_at — taahhüdün zamansal hassasiyeti bir işaretçi dönemidir.

Miras ön sürüm eşlemesi ve kilit açma tarafı toleransı: orijinal eşleme şuydu ceil((unlock_at - chain_genesis_time) / chain_period_seconds), bu da—yukarıdaki döneme göre hizalanmış durumda—tam bir dönem boyunca yayınlanan yuvarlak olanı seçti önce unlock_at, şifreli metnin tam olarak bir periyot erken çözülmesini sağlayarak. İki eşleşme tam olarak farklıdır +1 delta periyodu böldüğünde ve aksi yönde anlaşılır. Çünkü drand_round değiştirilemez olanın içine katlanır qub_id ön görüntü (§4.1), eski eşleme altında mühürlenmiş eserlerin yeniden türetilmesi mümkün değildir; §8 adım 6a turu çapraz doğrulamasını yapan doğrulayıcılar bu nedenle depolanmış olanı kabul ETMELİDİR drand_round eşit her ikisi de türetilmiş tur veya türetilmiş tur eksi biri (ve MUST, tlock dizesi turunun saklanan tura tam olarak eşit olmasını gerektirir). Tolerans, en erken geçiş imzasını en fazla bir dönem genişletir. Pact aşamalama servisi, aşamalı bir pact'i yeniden türettiğinde aynı toleransı uygular qub_id (sahne ve eş-imza aşamasında): eğer mevcut eşleme turu, taahhüt edileni yeniden üretmiyorsa qub_id ve delta dönemi böler, bir önceki tur ile tekrar dener ve hangi tura ait olursa olsun nihai anlaşmayı mühürler qub_id aslında bağlar—asla recompute edilmiş tur’a körü körüne bağlanmaz, bu da eseri kalıcı olarak türetilemez hale getirecektir.

Doğrulama: unlock_at Mühür zamanı gelecekte olmalı. unlock_at 10 yıldan fazla olmamalıdır created_at (uzun vadeli drand bağımlılık riskini sınırlamak için; kullanıcı arayüzü 2 yıldan uzun süreli kilit açma tarihleri için UYARMALIDIR).

5. Aktarım biçimi yeni tipleri

Aktarım biçimi yeni tipleri (newtypes), CBOR baytlarını JSON, ham düz metin veya diğer bayt kodlamalarıyla karıştırmaya karşı derleme zamanı güvenliği sağlar.

5.1 İnşa kuralları

// 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 İnşada doğrulama

from_encoded(), çift ayrıştırmayı önlemek için girdinin geçerli bir CBOR harita başlığıyla başladığını doğrulamalıdır (SHOULD). Tam yapısal doğrulama inşa zamanında değil, ayrıştırma zamanında gerçekleşir.

6. İçerik türü kayıt defteri

İzleyiciler bilinmeyen içerik türlerini açık bir kullanıcıya görünür hata ile reddetmek ZORUNDADIR. İzleyiciler bilinmeyen türleri metin olarak sunmaya çalışMAMALIDIR.

6.1 Pakt gövdesi (content_type = 0x03)

Bir pakt gövdesi, bir PactTerms değerinin kanonik CBOR kodlamasıdır:

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

Üç harita için kanonik CBOR anahtar sıraları §3.2'de verilmiştir. Toplam serileştirilmiş pakt CBOR 100 KB'yi aşMAMALIDIR (§6 ile eşleşir).

Şema ayırt edicisi. Bir structured/v1 paktında terms'teki ilk satır { key: "pact_schema", value: "structured/v1" } OLMALIDIR. Bu işareti olmayan satırlar "özel" paktlardır ve yapılandırılmış doğrulama veya şemaya duyarlı sunum almazlar.

Donmuş onay yuvaları. structured/v1 paktları bu anahtarlar altında tam olarak dört onay satırı taşır:

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

Her birinin value'su, (role, kind) çifti ile seçilen sekiz donmuş İngilizce dizeden biridir; burada role ∈ { seller, buyer, provider, client } ve kind ∈ { standard, capacity }. Dizelerin kendisi normatif protokol verisidir — her iki tarafın ML-DSA-65 imzaları, body_hash aracılığıyla tam baytlara taahhüt eder. Bunlar yerelleştirilMEZ; imzalanan gövde dilden bağımsızdır. Herhangi bir ifade değişikliği yeni bir şema sürümü gerektirir (structured/v2).

Sekiz dize, aramaları (acknowledgement_for(role, kind)) ve her birinin gerekçesi referans uygulama tarafından sabitlenir. Uyumlu uygulamalar bayt-aynı onay değerleri yaymak ZORUNDADIR; dört rol kombinasyonunun tamamını kapsayan altın-fikstür SHA3-256 gövde-özeti testleri herhangi bir kaymayı yakalar.

İzleyici görüntüleme sırası. Onay dizeleri, açıklama / kapsam satırlarının onaylardan önce sunulduğunu varsayan "yukarıda açıklandığı gibi" ("described above") gibi ifadeler içerir. İzleyiciler terms dizisini CBOR sırasında sunmak ZORUNDADIR; yeniden sıralama metnin anlamsal bütünlüğünü bozar.

Karşı taraf iletişimi. Taraf B'nin contact bilgisi geçerli bir e-posta adresi olduğunda, qub yükleme hizmeti, hazırlama anında otomatik olarak bir inceleme / birlikte imzalama davet e-postası gönderir ve nihai birlikte imzayı aynı adresin doğrulamasına bağlar (§9.7). Taraf B iletişimi olmayan paktlar yine de birlikte imzalanabilir, ancak yalnızca bant dışı bir kanal aracılığıyla — hizmet, eşleşen bir 15 dakikalık e-posta doğrulama işaretçisi üretemeyen birlikte imzalama isteklerini reddeder.

6.2 Karar gövdesi (content_type = 0x04)

Bir karar gövdesi, bir VerdictBody değerinin kanonik CBOR kodlamasıdır:

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
}

Kanonik CBOR anahtar sırası:

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

Toplam serileştirilmiş karar CBOR'u 8 KB'yi aşMAMALIDIR (yukarıdaki kayıt defteri satırıyla eşleşir).

Sonuç sıralı türü (enum). Tel baytı niyetten bağımsızdır; dört kategori — Right / Partial / Wrong / Unfalsifiable — karar taşıyan her niyetin sonuç uzayını kapsar. Niyete özgü etiketler (Right için "Bildim" / "Tuttum" / "Yayımlandı" / "Doğrulandı" gibi) izleyici tarafı sunum işidir ve üst qub'un niyetine göre çözümlenir — tel, dilden ve niyetten bağımsız kalır. 1..=4 dışındaki değerler kod çözmede reddedilmek ZORUNDADIR.

Üst bağlantısı. Bir karar qub'u, üst referansını gövdesinde taşıMAZ. Üst qub'un Arweave işlem kimliği, yükleme anında Parent-Tx-Id depolama etiketi olarak yayılır (§7 depolama-etiketi katmanı). Bu, gövdeyi kendi kendine yeten, imzalı bir öz-değerlendirme bildirimi olarak tutar; denetim zinciri ("ne hakkında haklı?") Arweave-etiketi araması üzerinden kurulur.

Kanıt URL güvenliği (normatif). evidence_url mevcut olduğunda, doğrulayıcılar (hazırlama tarafı, tel tarafı, Worker kenarı) şunları uygulamak ZORUNDADIR:

1. Yalnızca HTTPS. Dize, https:// bayt dizisiyle başlamak ZORUNDADIR. Başka herhangi bir şema — http, ftp, javascript, data, file vb. — reddedilir.
2. Uzunluk üst sınırı. ≤ 2.048 bayt (tarayıcı URL pratik sınırı).
3. NFC + düşmanca kod noktası denetimi. title ve reflection ile aynı kural — bidi-override / sıfır genişlik / etiket bloğu / BOM / C0 / C1 kod noktaları reddedilir. Tanım, Rust crate::handle::contains_hostile_text_codepoint ve TS workers/api/src/utils/unicode.ts::isHostileCodepoint ile eşleşir (üçü birlikte ilerletilmek ZORUNDADIR).
4. Boşluk yok, ASCII denetim karakteri yok. URL'nin herhangi bir yerindeki boşluk / DEL / 0x20 altındaki baytlar reddedilir — bidi kuralının kapsamadığı \n/\t enjeksiyon vektörünü kapatır.
5. Boş olmayan ana bilgisayar bölümü. https:// ile ilk /, ? veya # arasındaki her şey boş olmayan ZORUNDADIR.

Sunucu tarafında getirme yok. Worker, URL'yi vekille çekMEMELİ, getirMEMELİ ya da önizleMEMELİDİR. Protokol bir dize saklar; sunum, rel="nofollow noopener noreferrer" target="_blank" ile izleyici tarafında gerçekleşir ve bağlantı metniyle birlikte görünür bir ana bilgisayar gösterilir.

Düşünce. İsteğe bağlı, yaratıcının yazdığı düşünce metni ("ne değişti, ne öğrendin"). title ile aynı NFC + düşmanca kod noktası doğrulaması. Boş / yalnızca boşluk içeren girdi, oluşturma anında yok sayılır.

Şema sürümü. v1 yalnızca verdict_version = 0x01'i destekler. Gelecekteki şema güncellemeleri bu baytı artırır ve §12 uyarınca yeni bir protokol sürümüyle birlikte iner.

7. Mühürleme protokolü

Tam mühürleme dizisi. Her adım normatiftir.

 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.

Depolama etiket katmanı (out-of-band). Qub yükleme servisi, seçilen yükleme verisiyle birlikte kasıtlı olarak küçük bir depolama işlem etiketi seti ekler. Content-Type=application/octet-stream normatif olarak gereklidir. Referans hizmeti ayrıca, yaratıcı bunları görünür kılmayı seçtiğinde üç isteğe bağlı etiketi ekler: Intent (izinli-liste doğrulamalı oluşturma niyeti—announcement, thesis, prediction, letter, secret, commitment, proof, veya sistem tarafından üretilen verdict), Author (yaratıcının §9.3 genel anahtar parmak izi 64 karakterli küçük harfli onaltılık), ve Parent-Tx-Id (cevap zincirleri için üst qub’un depolama işlem kimliği, 43 karakterlik base64url).

The Author etiket qub başına katıl: referans oluşturucu uygulama bunu yalnızca kullanıcı mühürleme sırasında kamuya açık atıfı açıkça etkinleştirdiğinde ekler. Geçiş kapalıyken — varsayılan — hiçbiri Author etiket yazılmış ve qub zincirde atıfsız: kalıcı depolamada yüklemeyi bir yaratıcının kullanıcı adı, e-posta veya diğer qublarına bağlayan hiçbir şey yoktur. Geçiş açık olduğunda, Author parmak izi, yaratıcının seçtiğine karşılık gelir @handle §9.5 doğrulama zinciri aracılığıyla. Yanıt-zinciri ilişkileri ve Intent tanımlayıcı olmayanlardır. Özel teslimat için, dış ambalaj (§13) tanınabilir iç kısmı şifreler SealedQub artifact, bu yüzden depolanan sarmalayıcıları toplamak ve genel drand imzalarını elde etmek, K olmadan gövdeyi kurtarmak için hâlâ yetersizdir; depolama etiketleri bilinçli olarak halka açık meta veri olarak kalır.

Referans hizmet kasıtlı olarak App-Name, App-Version veya Type etiketlerini eklemez: bu tür herhangi bir tek değerli filtre, bir GraphQL sorgusuna tüm qub corpus'unu döndürür ki bu, sarmalayıcının yalnızca-gövde gizlilik kapsamıyla tutarsızdır.

Uyumlu bir doğrulayıcı, §11 üçüncü taraf doğrulaması için herhangi bir depolama etiketine bağımlı olMAMALIDIR; gövde özeti / qub_id / imza yalnızca iç CBOR'a taahhüt eder, asla etiket setine değil.

8. Açma protokolü

Tam açma dizisi. Her adım normatiftir.

 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. Yazarlık imzalama

9.1 Gerekçe

qub'lar kalıcı depolamada saklanır. Yazarlık imzaları süresiz olarak sahteciliğe karşı dirençli kalmalıdır, bu nedenle v1.0, güvenliği qub'un kalıcı yaşam süresi içinde bozulabilecek klasik bir şema yerine post-kuantum ML-DSA-65 şemasını (FIPS 204) kullanır.

9.2 Algoritma kayıt defteri

Protocol-v1 görüntüleyicileri, dışındaki her değeri RED ETMELİDİR {0x00, 0x01}, dahil çekingen 0x02 değer. Rezervasyon kazara tekrar kullanımını önler; bu değildir aktivasyon. Bunu aktive etmek, §15'te açıklanan yönetilen değişikliği gerektirir.

9.3 İmzalı ön görüntü inşası

İki ön görüntü sürümü var olmuştur. Tüm imzalar V2 kullanmak ZORUNDADIR ve doğrulayıcılar yalnızca V2'yi kabul etmek ZORUNDADIR. Eski V1 ön görüntüsü (tarihsel referans için aşağıda belgelenmiştir), V2 geçişi sırasında yalnızca doğrulama amaçlı bir yedek olarak kabul ediliyordu; bu yedek kullanımdan kaldırılmıştır ve yalnızca V1 olan bir imza artık reddedilir.

V2 (güncel — tüm yeni yazar imzalaması tarafından ve pakt hazırlama / birlikte imzalama akışının her iki imzası tarafından üretilir):

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

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

signature = Sign(author_secret_key, sig_input)

sender_label_hash, title_hash (§4.2.1) ile aynı yokluk-nöbetçisi kuralını izler: 32 sıfır bayt geçerli bir SHA3-256 çıktısı değildir, bu nedenle "yok" hiçbir zaman mevcut bir etiketle çakışamaz. Tüm alanlar sabit genişliktedir, bu nedenle ön görüntü, uzunluk önekleri olmadan belirsizlik taşımaz.

V1 (eski — KULLANIMDAN KALDIRILDI; artık üretilmez ve doğrulamada artık kabul edilmez):

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 ön görüntüsü sender_label ve reply_to'yu dışarıda bırakıyordu. V2'ye geçiş sırasında yalnızca doğrulama amaçlı bir yedek olarak kabul ediliyordu; bu yedek o zamandan beri kullanımdan kaldırılmıştır — doğrulayıcılar yalnızca V2 ön görüntüsünü kabul etmek ZORUNDADIR. Tanım burada tarihsel referans için ve aşağıdaki etki alanı ayırıcısını açıklamak için tutulmuştur. Yalnızca V1'e karşı doğrulanan bir imza, bir doğrulama hatası olarak ele alınmak ZORUNDADIR.

Etki alanı ayırıcıları: "QUB_AUTHOR_SIG_V1" / "QUB_AUTHOR_SIG_V2" her biri 17 ASCII bayttır ([0x51, 0x55, 0x42, 0x5F, 0x41, 0x55, 0x54, 0x48, 0x4F, 0x52, 0x5F, 0x53, 0x49, 0x47, 0x5F, 0x56, 0x31/0x32]). Dolgu yok. Farklı ayırıcı, iki yapıyı etki alanı olarak ayırır, bu nedenle bir ön görüntü üzerindeki bir imza asla diğeri olarak doğrulanamaz.

org_id_present baytı: unlock_at'ı izleyen bayt 0x00 OLMALIDIR. Referans uygulama bunu crates/qub-core/src/signing.rs içinde ORG_ID_PRESENT_INDIVIDUAL = 0x00 sabiti olarak sunar; doğrulama için sig_input'u yeniden oluşturan izleyiciler aynı baytı yaymak ZORUNDADIR.

İmza kapsamı — neyi kapsar ve neyi kapsamaz. V2 sig_input'u doğrudan version, qub_id, body_hash, unlock_at, sender_label ve reply_to'ya taahhüt eder (artı sabit etki alanı ayırıcısı ve org_id_present baytı). qub_id'nin kendisi §4.1 ön görüntüsü aracılığıyla version, content_type, created_at, unlock_at, outcome_at, drand_round ve body_hash'ten türetilir, bu nedenle bu alanlarda yapılan herhangi bir değişiklik farklı bir qub_id üretir ve imzayı geçişli olarak geçersiz kılar. Bu nedenle kimliği doğrulanmış yüzey şudur:

Neden yalnızca V2 kabul edilen ön görüntüdür.

• Kullanımdan kaldırılan V1 ön görüntüsü altında, depolanan baytlara yazma erişimi olan bir taraf, sender_label'ı ("Alice" → "Mallory") değiştirebilir veya reply_to'yu yeniden bağlayabilir — ve tur sonrası yeniden şifreleyebilir — yazar imzasını geçersiz kılmadan, çünkü hiçbir alan imzalı ön görüntüde değildi. V2 her ikisini de kapsar, bu nedenle her iki alandaki herhangi bir değişiklik doğrulamayı "başarısız" duruma çevirir. Doğrulayıcılar artık yalnızca V2'yi kabul ettiğinden, bu değiştirme her imza için kapatılmıştır: hiçbir alanı bağlamayan (yani yalnızca V1'e karşı doğrulanan) bir imza, düşürülmek yerine doğrudan reddedilir.
• Zarftaki author_pubkey, gerçek kimlik dayanağı olarak kalır — izleyiciler görüntüleme kimliğini sender_label'a güvenmek yerine author_pubkey'den (§9.5 onay katmanı aracılığıyla) türetmek ZORUNDADIR.

sender_label veya reply_to'yu son kullanıcılara gösteren uygulamalar, kimliği doğrulanmış kimliği (açık anahtar parmak izi, onay) etiket yerine birincil kimlik sinyali olarak yüzeye çıkarmak ZORUNDADIR.

9.4 Doğrulama prosedürü

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

İmza doğrulama en pahalı işlemdir (özellikle ML-DSA-65). Daha ucuz tüm kontroller (özet, qub_id, unlock_at) geçtikten sonra yapılmalıdır (SHOULD).

9.5 Kimlik onayları

Kimlik onayları — author_pubkey'in qub kullanıcı adı, e-posta adresi, sosyal kullanıcı adı veya parola anahtarı kimlik bilgisi gibi insan tarafından tanınabilen kimlik iddialarına eşlenmesi — izleyici tarafında aşamalı bir geliştirmedir ve imza doğrulaması için gerekli değildir. Onayları bir görüntüleme kimliğine çözen izleyiciler şu önceliği uygulamak ZORUNDADIR:

handle > email > social > fingerprint

Parmak izi yedeği, SHA3-256(author_pubkey)'in küçük harf onaltılığıdır; herhangi bir imzalı qub için her zaman kullanılabilir. İzleyiciler bunu görüntüleme için kısaltABİLİR — referans izleyici, qub: ardından ilk ve son dört baytı sunar (qub:<8 hex>…<8 hex>).

Uyumlu bir doğrulayıcı, qub API'sine başvurmadan, kalıcı depolama ve drand'ın ötesinde herhangi bir ağ olmadan ve herhangi bir sunucu tarafı araması olmadan §9.4'teki her kontrolü tamamlayabilir. Onay çözümleme, yalnızca imza doğrulaması başarılı olduktan sonra gerçekleştirilen ayrı bir en iyi çaba adımıdır.

9.6 Boyut etkisi

500–2.000 bayt'lık bir metin qub için ML-DSA-65 depolanan boyutu kabaca üç katına çıkarır. Mutlak maliyet ihmal edilebilir düzeydedir.

9.7 Birlikte imzalayan doğrulaması (Pakt ikili anlaşmaları)

İkili anlaşmalar için (content_type = 0x03), ikinci bir imza katmanı her iki tarafın da aynı koşullara onay verdiğini kanıtlar.

Zarf alanları:

• cosigner_pubkey: Karşı imzalayanın (Taraf B) ML-DSA-65 açık anahtarı.
• cosigner_signature: Yazarla aynı sig_input üzerindeki imza (§9.3).

Her iki alan da birlikte mevcut olmak veya her ikisi de yok olmak ZORUNDADIR. Yalnızca biri mevcutsa, izleyiciler bir bütünlük hatası bildirmek ZORUNDADIR.

Doğrulama prosedürü:

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

Özellikler:

• Birlikte imzalayan, yazarla aynı sig_input'u imzalar — her iki taraf da aynı qub_id, body_hash ve unlock_at'a (ve V2 altında, aynı sender_label_hash ve reply_to_or_zero'ya) taahhüt eder.
• Karşı imzalayanın ham zarf baytlarına erişimi olmadan V2 ön görüntüsünü yeniden oluşturabilmesi için, hazırlama hizmeti, hazırlama anında bir pakt zarfının sender_label'ının pact_terms.party_a.label değerine eşit olmasını ve reply_to'nun bulunmamasını zorunlu kılar. Her ikisi de her referans istemci paktı için geçerlidir; ihlal eden zarflar hazırlamada reddedilir.
• qub_id türetmesi (§4.1) birlikte imzalayan alanlarını İÇERMEZ. Mevcut bir zarfa bir birlikte imzalayan eklemek qub_id'yi değiştirmez.
• Bir pakt yalnızca yazar tarafından imzalanmış (tek taraflı taahhüt), yalnızca birlikte imzalayan (alışılmadık) veya her ikisi (tam ikili kanıt) olabilir.

E-posta bağlama kapısı (operasyonel). Hazırlanan bir pakt bir Taraf B e-posta iletişimi taşıdığında (§6.1), qub yükleme hizmeti, hem hazırlama kimliği hem de bu iletişimin normalleştirilmiş e-posta özeti ile eşleşen kısa ömürlü bir e-posta doğrulama işaretçisi mevcut olmadıkça birlikte imzalama isteğini reddetmek ZORUNDADIR. İşaretçi, sihirli bağlantı belirteci bir staging_id taşıdığında ve doğrulanmış adres SHA-256(normalise_email(party_b.contact)) ile eşleştiğinde /api/v1/auth/verify tarafından yazılır — burada normalise_email(addr) yerel bölümün büyük/küçük harfini korur ve yalnızca etki alanı bölümünü küçük harfe çevirir (RFC 5321 §2.3.11 uyarınca) ve buradaki SHA-256, NIST FIPS 180-4 özetidir (§4 türetmelerinde kullanılan SHA3-256'dan farklı) — ve verildikten 900 saniye (15 dakika) sonra sona erer. Bu operasyonel bir kimlik taklidine karşı kapıdır, zincir üzerindeki qub kanıtının bir parçası DEĞİLDİR — §11'i yeniden oynayan üçüncü taraf bir doğrulayıcının yalnızca kalıcı depolama ve drand'a ihtiyacı vardır, herhangi bir sunucu tarafı araması olmadan. İşaretçi yalnızca sunucu tarafında bulunur ve asla imzalanmış gövdenin bir parçası değildir.

Boyut etkisi (ML-DSA-65 yazar + birlikte imzalayan):

10. Markdown sunumu ve temizleme

Bu bölüm güvenlik açısından kritiktir. İzleyici, metin qub'larını (content_type = 0x01) kısıtlı bir Markdown alt kümesi kullanarak sunar.

10.1 İzin verilen öğeler

• Başlıklar: #'tan ####'a (##### veya ###### yok)
• Vurgu: kalın (**), italik (*), üstü çizili (~~)
• Listeler: sıralı (1.) ve sırasız (-, *)
• Alıntı blokları (>)
• Kod: satır içi aralıklar (```) ve çitlenmiş bloklar (`````)
• Yatay çizgiler (---)
• Satır sonları (iki sondaki boşluk veya boş satır)
• Paragraflar

10.2 Yasaklanan öğeler

10.3 Uygulama

Uygulamalar bir kara liste değil, katı bir izin listesi ayrıştırıcısı kullanmak ZORUNDADIR. Önerilen yaklaşım:

1. Markdown'ı pulldown-cmark (veya eşdeğeri) kullanarak ayrıştırın.
2. AST'de gezinin ve izin listesinde olmayan herhangi bir düğümü atın (§10.1).
3. Bağlantı düğümleri için: URL'yi tıklanabilir bir <a> öğesi olarak değil, görünür metin olarak yayın.
4. Filtrelenmiş AST'yi tipli bir ara temsile dönüştürün (örneğin, yalnızca güvenli varyantları olan bir MarkdownNode enum'u). Bu IR'de ham HTML yapısal olarak temsil edilemez.
5. Tipli IR'den hedef görünüm katmanına (örneğin, reaktif görünüm bileşenleri, DOM düğümleri) sunum yapın. Hiçbir noktada HTML dize birleştirme veya innerHTML kullanılmaz.

Kara liste yaklaşımları kırılgandır çünkü yeni Markdown uzantıları veya ayrıştırıcı tuhaflıkları filtrelenmemiş öğeler getirebilir. Tipli AST yaklaşımı, XSS'yi yapısal olarak imkansız hale getirir — keyfi HTML taşıyabilecek bir varyant yoktur.

10.4 Boyut ve yapı sınırları

• Maksimum sunulan başlık derinliği: #### (H4). ##### ve daha derin olanlar kalın metin olarak sunulur.
• Paragraf sayısında sınır yoktur (gövde boyutu sınırları §6'da kısıtlamadır).
• Çitlenmiş kod blokları: MVP'de söz dizimi vurgulama yok. Monospace önceden biçimlendirilmiş metin olarak sunulur.

11. Üçüncü Taraf Doğrulaması

Saklanan baytları (ve özel/sarılı bir qub için K'yı) elinde bulunduran herhangi bir üçüncü taraf yapabilir kriptografik eseri qub işbirliği olmadan doğrulayın. Bağımsız bir şekilde zaman damgalı varoluş iddia ayrıca doğrulanmış olmasını gerektirir per-qub kalıcı depolama dahil edilmesi veya doğrulanmış bir §16 şeffaflık günlüğü kanıtı.

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.

Doğrulama neyi kanıtlar:

Doğrulama neyi kanıtlamaz:

Uygulanan şeffaflık günlüğü (§16), doğrulamayı qub'lar arasında genişletir muhafaza kanıtlı sipariş verme ve güvene dayalı olmayan üst sınır taahhüt süresi (the çapa blok zamanı), yaprak türü ile sınırlıdır (§16.11). Yazar bilgisi eklemez veya niyet; varsayılan byte-görmez yükleme yolu için kendisi kanıtlamaz body_hash veya drand_round, bu da eser kontrollerinden gelmeye devam ediyor.

12. Sürümleme ve Yayın Kontrolü

Belge sürümleri, iç kablo protokolü ve dış kapsayıcı ayrıdır sürüm alanları. Bu nedenle yalnızca belgeye yönelik bir açıklama sessizce yapmaz baytları değiştirin ve gelecekteki bir tel geçişi, editoryal gibi görünüp kılık değiştiremez revizyon.

12.1 Belge Sürüm Yayını

Bu spesifikasyon, semantik belge sürümlerini kullanır (MAJOR.MINOR.PATCH) ve değiştirilemez bir Git etiketi adlandırılmış protocol-v<release>.

• Yama: uygun baytları veya gerekli davranışı değiştirmeyen doğruluk veya editoryal düzeltme.
• İNCE: geriye dönük uyumlu normatif ekleme, yeni kayıt defteri girişi veya yeni bağımsız sürümlenmiş yan dosya formatı.
• BÜYÜK: uyumsuz normatif değişiklik, yeni bir gerekli tel yorumu dahil.

Yayın durumu bunlardan biridir Taslak (henüz normatif değil), Mevcut (tek önerilen uygulama hedefi), veya Yerini almış (tarihsel olarak saklandı doğrulama). Versiyonsuz /protocol rota Mevcut sürümü gösterir; sürüm etiketi, kaynağını ve onunla yayınlanan her yerel sürümü tam olarak korur. Durum veya sürüm numarasını değiştirmek, bu tabloyu ve sürümü güncellemeyi gerektirir aynı gözden geçirilmiş değişiklikte tarih.

12.2 Protokol Sürümü

The version her ikisinde de alan (u8) SealedQub ve QubEnvelope ana protokol sürümünü tanımlar.

• İzleyiciler, bilinmeyen ana sürümleri açık bir hata ile reddetmelidir.
• Bilinen bir ana sürüm içinde, çözücüler bilmeyen harita anahtarlarını (§3.1) REDDETMEK ZORUNDADIR — şema evrimi yeni bir şey tanıtılarak gerçekleşir version, mevcut çözücüler atlayacak anahtarları ekleyerek değil. (Bu spesifikasyonun önceki revizyonları bilinmeyen isteğe bağlı alanları tolere etmeyi izinliyordu; bu hüküm geri çekildi — o hüküm encode(decode(x)) önleyici olmayan ve pakt yüklerinde gizli imzalı içerik vektörü açtı.)
• İçerik türleri (content_type) ve imza şemaları (sig_alg) sürüm engeline tabidir: yeni değerler yalnızca yeni bir protokol sürümü veya açık bir kayıt güncellemesi ile tanıtılabilir.

12.3 Protokol Sürüm Geçmişi

12.4 İleri Dönük Uyumluluk

§3.2 kanonik sıralamasında olmayan (bilinmeyen) CBOR harita anahtarlarına sahip bir QubEnvelope ile karşılaşan bir v1 görüntüleyici, bunu bir çözümleme hatası ile reddetmelidir (§3.1). İleriye dönük uyumluluk, buna bağlıdır version alan, anahtar toleransı üzerinde değil: gelecekteki eklemeler — hatta küçük meta veriler bile — yeni bir sürüm altında gönderilir version v1 görüntüleyicisinin, imzaların taahhüt ettiği içeriği sessizce atmak yerine açık bir “daha yeni protokol” hatası ile reddettiği değer.

Bir v1 görüntüleyici ile karşılaşan sig_alg = 0x01 (ML-DSA-65) fakat ML-DSA-65 doğrulama desteği olmayan, qub içeriğini tamamen reddetmek yerine “imza mevcut ama doğrulanabilir değil” uyarısı ile görüntülemelidir. Bugünkü referans uygulama her şeyi reddeder sig_alg başka bir değer 0x00 ve 0x01 çünkü v1 kaydı başka geçerli bir algoritma içermemektedir — sıkı reddetme ve yumuşak hata gözlemsel olarak üçüncü bir algoritma kaydedilene kadar aynıdır. Yukarıdaki yumuşak hata davranışı, §9.2 yeni bir giriş kabul ettiğinde yük taşıyıcı hale gelir ve referans görüntüleyici o noktada yumuşak hataya güncellenecektir.

12.5 Dış Kaplama Sürümü

§13'te tanımlanan OuterWrapper kendi taşır version bayt, bağımsız of SealedQub.version ve QubEnvelope.version. İki sürüm alanı ayrı ayrı evrilir: gelecekte kuantum güvenli simetrik bir değişim, iç protokol sürümüne dokunmadan sarmalayıcı baytı yükseltir ve gelecekteki bir protokol katmanı eklemesi (örneğin, yeni bir zarf alanı) sarmalayıcı bayta dokunmadan iç sürümü yükseltir.

İzleyiciler, bilinmeyen sarmalayıcı sürümlerini açık bir hata ile REDDETMEK ZORUNDADIR. Protokol, somut bir geçiş sürücüsü ortaya çıkana kadar (ör. farklı bir AEAD lehine NIST rehberliği) sarmalayıcı sürüm alanını kasıtlı olarak dar tutar; a 0x02 Yuvalar, algoritmayı tanıtan aynı revizyonda tahsis edilecektir.

13. Dış şifreleme sarmalayıcısı

13.1 Gerekçe

Protokol katmanları (QubEnvelope → tlock → SealedQub) mühürlü bir qub'u zamana kilitli yapar: gövde unlock_at'a ve drand tur imzası yayınlanana kadar okunamaz. Ancak açılmadan sonra, tur imzası kamuya açıktır ve SealedQub'un kanonik CBOR şekli tanınabilirdir, bu nedenle kalıcı depolama işlemlerini indeksleyen bir hasatçı, tüm qub corpus'unu toplu olarak şifresini çözebilir.

Özel teslimat için, dış şifreleme sarmalayıcısı, kanonik arasına ek bir simetrik AEAD katmanı yerleştirerek o kanalı kapatır SealedQubCbor ve depolanan byte'lar. Tarayıcı-mühür yolunda, 256-bit anahtar K yaşamlar sadece teslimat URL'sinin URL parçasında ve kullanıcı cihazlarında; tarayıcılar URL parçalarını sunuculara iletmez, bu yüzden qub.social, her depolama geçidi ve her ikisinin önündeki her CDN gözlemlenebilir olarak kördür K. Bir özel qub'un saklanan temsili, bu nedenle, oluşturucunun paylaşmayı seçtiği URL olmadan düz metni geri kazanılamayan opak şifrelenmiş metindir. Halka açık teslimat kasıtlı olarak bu katmanı hariç tutar (§13.8).

Net etki:

• Özel teslimat için sayma direnci. OuterWrapper tanınabilir yapılandırılmış CBOR olarak kalır—aslında rastgele baytlardan tamamen ayırt edilemez değildir—ama şifreli metin alanı tanınabilir içeriği gizler SealedQub şekil. "GrafQL-sorgusu ile qub-şekilli yüklemeler için hasatçı stratejisi, kamu drand imzaları ile toplu şifre çözme" olarak belgelenmiş olan strateji, K olmadan düz metinle sona ermez.
• Varsayılan özel tarayıcı akışı için kripto-parçalama gizlilik duruşu. qub.social, bu saklanan nesneleri varsayılan sunucu tarafı verilerinden çözememektedir. Açık kurtarma, kamuya teslim ve güvenilir sunucu tarafı mühürleme farklı açıklanmış güven sınırlarına sahiptir.
• İki kademeli gizlilik merdiveni. Varsayılan = bağlantı kontrollü erişim (bu bölüm). Alıcı tarafından şifrelenmiş özel qub'lar (henüz belirtilmemiş rezerve edilmiş Birinci Aşama 2 özelliği) ikinci katman olarak üst üste gelir.

13.2 Katmanlama

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

Protokol katmanındaki mühürleme ve açma (§7, §8) sarmalayıcı sınırının altında değişmez; sarmalayıcı seal()'ın çağrı yerinde takılır ve unlock()'ın çağrı yerinde çıkarılır.

13.3 OuterWrapper veri yapısı

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
}

Alan değişmezleri.

• version EŞİT OLMALI 0x01 v1.0 sarmalayıcı baytları için.
• qub_id Eşit OLMALIDIR qub_id Ambalajı açıldıktan sonra SealedQub alanı kurtarıldı. Her ikisi de referans wrap_sealed_qub ve unwrap_sealed_qub iç CBOR'u çözümleyin ve bu eşitliği doğrudan uygulayın; AAD bağlaması ise dış kısmın sarmalandıktan sonra değiştirilmesini ayrı olarak önler qub_id kimlik doğrulaması başarısız.
• nonce Her sarma işlemi için CSPRNG tarafından taze üretilmiş 96 bit (12 bayt) OLMALIDIR. Aynı anahtar altında bir nonce'un yeniden kullanılması, açık metni geri kazanan AEAD nonce-yeniden kullanım saldırılarına izin verir; üreticiler ŞU ŞEKİLDE işlem yapMALIkey, nonce) çiftlerini tek seferlik olarak.
• ciphertext AES-256-GCM çıktısı: 16 baytlık kimlik doğrulama etiketiyle birleştirilmiş şifreli metin baytlarıdır. ciphertext.len() == SealedQubCbor.len() + 16 tam olarak.

CBOR kodlaması. §3 uyarınca kanonik CBOR, aynı anahtar sıralama kuralıyla (artan kodlanmış bayt uzunluğuna göre sıralı, sonra sözlüksel olarak). Dört anahtar şudur:

Bu nedenle OuterWrapper CBOR'unun ilk baytı, 4-girişli bir harita için kesin uzunluklu harita başlığıdır (0xA4).

13.4 qub_id'ye AAD bağlama

Sarmalayıcı, qub_id'yi AEAD ek kimliği doğrulanmış veri olarak bağlar. Bu, üç sınıf saldırıya karşı yük taşıyan yapısal savunmadır:

qub_id'yi sarmalayıcı düz metninde taşımak, numaralandırma bağışıklığını anlamlı ölçüde zayıflatmaz — qub_id'nin kendisi §4.1 ön görüntüsünün özetten kurtarılamayan ön görüntüsüz bir SHA3-256 özetidir ve sarmalayıcı baytlarını zaten toplayan bir numaralandırıcı, görünür qub_id'den yüklemenin varlığından çıkarabileceğinden daha fazla bir şey öğrenmez.

13.5 Sarmalama ve sarmalama açma algoritmaları

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

Hata modu çöküşü. Yanlış K, yanlış nonce, AAD uyuşmazlığı ve kurcalanmış şifreli metin, hepsi aynı DECRYPT_FAILED hatasını üretir. Bu, kasıtlı bir AEAD özelliğidir: hata modunu ayırt etmek, uzaktan bir saldırganın hatalı biçimlendirilmiş sarmalayıcılar göndererek ve yanıtı zamanlayarak araştırabileceği bir yan kanal oluşturur. Referans uygulamalar tüm AEAD hatalarını tek bir hata şekline daraltmak ZORUNDADIR.

13.6 Anahtar materyali ve dağıtım

Sarmalama anahtarı K, bir CSPRNG tarafından qub başına üretilen 256-bitlik tek tip rastgele bir değerdir. Referans uygulamalar bunu şuradan alır:

• WASM yaratıcısı: getrandom (wasm_js arka ucu altında WebCrypto).
• Sunucu tarafı mühürleme API çağırıcısı: kendi yerel CSPRNG'si; çağırıcı K'yı wrapper_key_b64url olarak sağlar ve saklar. Worker, sarmalayıcı için K'yı bellekte kullanır ancak onu kalıcı kılmamalıdır (MUST NOT). Bu, bir idempotent yeniden denemenin, tek seferlik sunucu tarafında üretilen bir gizli değere bağlı kalmak yerine çağırıcının sakladığı yetkiyi kullanarak redakte edilmiş bir yanıtı kurtarmasına olanak tanır.

Dağıtım: K, URL-güvenli base64 (RFC 4648 §5, dolgu yok) olarak kodlanmak ve teslim URL'sine parça bileşeni olarak eklenmek ZORUNDADIR:

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

Parça, uyumlu bir tarayıcı tarafından hiçbir sunucuya iletilmez. Tam teslim URL'sini — parça dahil — kullanıcının cihazının ötesinde kalıcı kılan kurtarma kanalları (sunucu tarafı geçmiş dizini, opt-in e-posta otomatik gönderme), varsayılan kripto-parçalama duruşuna karşı açık bir takastır ve açık kullanıcı onayına kapılı olmak ZORUNDADIR.

Parça kaybı. Bir kullanıcı URL parçasını kaybeder ve kurtarma kanalı yoksa, qub okunamaz. Bu, tasarımın yük taşıyan takasıdır ve mühürleme anında kullanıcıya açıklanmak ZORUNDADIR. MVP, mühürleme anı açıklamasını açık "bu URL'yi kaydedin" metni ve opt-in yapan kullanıcılar için doğrulanmış-e-posta kurtarma kanalı ile güçlendirir.

13.7 Bu bölümün kapsamı dışında

• Yazarlık imzalama (§9) değişmedi: imzalar iç kısmın içinde hesaplanır QubEnvelope ve unwrap → tlock decrypt → CBOR parse işleminden sonra geri kazanılır.
• Alıcı-açık anahtar şifrelemesi (rezervlenen recipient_pubkey Alan) bugünkü özel, bağlantı-özelliği sınırlı sarmalayıcı modundan farklı gelecekteki bir özelliktir.
• Mevcut sunucu tarafı anlaşma ortak imza akışı, açık/yalın yayımlar SealedQubCbor görünürlük ile 0x01; tarayıcıya özel K-gizlilik modelini karşılayamaz çünkü nihai mühürleme, sunucu aracılı ortak imzadan sonra gerçekleşir. Gelecekteki bir özel anlaşma üreticisi, içeriğin türüne bakmayan aynı sarmayı kullanabilir.

13.8 Kamu qub'ları (sarmalayıcı atlanması)

Dış sargı teslimat katmanında isteğe bağlı. Bir yaratıcı bir qub'u mühürleyebilir halka açık, bu durumda kanonik SealedQubCbor depolama hattına girer doğrudan, hiç OuterWrapper katman ve anahtar yok K:

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

Bir halka açık bar zaman kilitli fakat bağlantı ile erişim sınırlı değil: drand turu yayınlanana kadar okunamaz kalır (tlock katmanı değişmeden kalır), ancak kilit açıldıktan sonra depolama işlem kimliğine sahip olan herkes bunu çözebilir — herhangi bir URL parçasına gerek yoktur, çünkü yoktur K. Bu, sunucunun yönlendirmek zorunda olduğu yüzeyler için kasıtlı bir ticarettir: bildirim açılma e-postaları, parçacığa ayrılmamış oEmbed/otomatik gömme bağlantıları ve daha zengin gönderi açılma SEO’su, sunucunun asla elinde bulundurmadığı bir gizli olmadan çalışan bir bağlantıya ihtiyaç duyar (§13.6). Özel bir qub yine de açıkça kullanabilir <qub-embed src="full_delivery_url"> yayıncı tüm parça içeren yeteneğini sağladığında form

Bir üreticinin hesaba katmak ZORUNDA olduğu sonuçlar:

• Sayımlama bağışıklığı yok. Halka açık qub'lar, yapıları gereği §13.1 sıralama-bağışıklık özelliğinden vazgeçer. Referans yükleme servisi bir damga vurur Visibility: public onlarda (ve sadece onlarda) kalıcı depolama etiketi bulunur, bu yüzden kasıtlı olarak keşfedilebilirler; özel qublar böyle bir etikete sahip değildir ve byte-ayrıştırılamazlıklarını korur.
• Düz metin başlığı mühürleme sırasında açığa çıktı. §3.2 title alan içi düz metin SealedQubCbor. Paketlemenin altında, bir izleyici sağladığında gizlenir K; sarmalayıcı olmadan, kalıcı depolamada tüm dünya tarafından okunabilir yükleme anından itibaren, kilidi açmadan önce. Uyumlu oluşturucu uygulamaları bunu mühürleme zamanında açıklamak ZORUNDADIR.
• Tespit yapısal ve karşılıklı olarak kontrol edilir. Uygun bir görüntüleyici/gömme, iki saklanan şekli ayrıştırma ile ayırt eder: ayrıştırıldığında şu şekilde görünen baytlar OuterWrapper çıkar-ile-K yol; çıplak olarak ayrıştırılan baytlar SealedQubCbor doğrudan kabul edilir. Kurtarılan iç değer MUTLAKA uyumlu olmalıdır (0x00 paketlenmiş/özel için, 0x01 çıplak/kamu için). qub_id görünürlüğe bağlamaz, ancak kanonik SealedQub baytlar bunu taşır, bu yüzden genel ve özel iç kodlamalar bayt olarak aynı değildir.

Özel (sarmalanmış) varsayılan olarak kalır; kamu, açık bir qub-başına yaratıcı seçimidir.

14. Test vektörleri

14.1 qub_id türetmesi

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

Uygulamalar AYNIYI üretmelidir body_hash ve qub_id bu girdiler için değerler. Bu test vektörü YAZILACAK olan ilk birim testi OLMALIDIR. Yukarıdaki kanonik değerler referans uygulama tarafından hesaplanmış ve bit-bitiyle eşleşMELİDİR. Tarihsel olarak lansman öncesi prototip düzenlemeler (ilk ikisine bağlı canlı qub'lar yoktu) öncesinde 92 bayt kullanılmıştır outcome_at (3d9fc2390eab043d38a1669ed3b71be76f9eefe872b9569ab1aaa027b88392b0) ve ekledikten sonra 100 bayt outcome_at_or_zero (b0d032898ad629795150fdcb3f84e518f59ed05b7a2a82bc24ebdb87f52144ed). Mevcut 108 baytlık düzen daha sonra eklendi drand_round ve QUB_ID_V2 alan ayırıcı. Eski 108 baytlık bir vektör, eski ceil yuvarlak haritalama (drand_round = 4695445) ve üretildi 3a9fcb31b750d985c262fada6d4f777fd6a28be831d941d85c131f5a4bbaf8a4—hala geçerli qub_id o tur giriş için, yukarıdaki örnek §4.3 mevcut tur eşlemesini takip ederken.

14.2 Kilit-Açma Turu Eşlemesi

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

4675286. tur yayımlanıyor 1595431050 + (4675286 - 1) * 30 = 1735689600—tam olarak unlock_at, daha önce hiç. (Miras ön sürümü ceil eşleme verdi 4675285, yayınlandı 1735689570—30 saniye erken; doğrulayıcılar §4.3 uyarınca eski turu kabul eder.)

14.3 Kanonik CBOR gidiş-dönüşü

Uygulamalar, tüm geçerli girdiler için serialize(parse(serialize(qub))) == serialize(qub) olduğunu doğrulamak ZORUNDADIR. Bu tek bir vektör değil, bir özellik testidir.

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)

Kanonik CBOR baytları ve SHA3-256 body_hash, referans uygulama tarafından hesaplanır. Uygulamalar bu girdi için bayt-aynı CBOR üretmek ZORUNDADIR.

Uygulamalar ayrıca, tüm geçerli PactTerms girdileri için serialize(parse(serialize(pact))) == serialize(pact) olduğunu doğrulamak ZORUNDADIR (özellik testi).

14.5 Dış sarmalayıcı diller arası vektörler

Dış sarmalayıcı (§13), crates/qub-core/tests/vectors/wrapper_v1.json konumunda ayrı bir kanonik fikstüre sahiptir. Her vaka, opak onaltılık girdiler olarak bir (key, nonce, qub_id, sealed_cbor) demetini sabitler ve belirli bir expected_wrapper_hex çıktısını onaylar. Her iki referans uygulama da aynı JSON dosyasını tüketir:

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

Aygıt şu anda üç düşük seviyeli sarmalayıcı vakayı sabitliyor. Bunlar deterministik olarak test ediyor. OuterWrapper §13.8 teslimat-şekli değişmezinden bağımsız olarak kodlama ve AEAD birlikte çalışabilirliği; özellikle, tarihî ad basic-text-public ve onun içi visibility = 0x01 yap değil oluşan sarılmış baytları uyumlu bir genel teslimat yapın. Bir üretici, genel iç baytları çıplak olarak yine de saklamalı ve yalnızca özel baytları sarmalı (0x00) iç baytlar.

Uygulamalar, kaydedilen girdiler için bayt-aynı expected_wrapper_hex üretmek ZORUNDADIR. Fikstürü yeniden oluşturmak QUB_REGEN_VECTORS=1 cargo test -p qub-core --test wrapper_vectors gerektirir ve kasıtlı biçim değişiklikleri için ayrılmıştır.

15. Kripto profil yönetişimi (Gelecek)

Bu bölüm v1 için bilgilendiricidir ve qub'un kriptografik ilkellerinden herhangi birine ikinci bir algoritma girdiği ilk anda normatif hale gelir.

15.1 Mevcut duruş

Protokol v1, ilkel başına tam olarak bir algoritmaya bağlanır:

• İmza: ML-DSA-65 (sig_alg = 0x01; 1952 baytlık açık anahtar, 3309 baytlık imza) ve imzasız (sig_alg = 0x00). Kod tabanı ayırır 0x02 Ed25519 için, ancak protokol v1 bunu etkinleştirmez; bir v1 doğrulayıcı HER zaman reddetmelidir sig_alg dışarı {0x00, 0x01}.
• Zaman kilidi: drand quicknet yalnızca — zincir hash'i, genel anahtarı, başlangıç zamanı ve dönem, referans tarafından taşınan sabit ağ parametreleridir DrandTimelockProvider::quicknet() (crates/qub-core/src/tlock.rs) ve config/drand-endpoints.json.
• Dış kaplama: AES-256-GCM v1 yalnızca (§13).

Doğrulayıcılar şu anda her aktif ilkeye göre anahtar ve imza uzunluklarını sabit kodlamaktadır. The sig_alg ve wrapper-sürüm baytları açık seçicilerdir, ancak v1 bant içi müzakere yapmaz ve yalnızca yukarıdaki aktif değerleri kabul eder.

15.2 Hedeflenen şekil

Protokole ikinci bir algoritma girdiğinde, doğrulayıcı, ilkel başına izin verilen değerlerin tam setini — sig_alg'ler, drand zincirleri, sarmalayıcı sürümleri, içerik türleri — listeleyen adlandırılmış bir CryptoProfile (örneğin ExqubV1) için yapılandırılacaktır. Profil doğrulama zamanında sabitlenir, asla bant içinde müzakere edilmez. Aktif profilin dışındaki herhangi bir değer reddedilir.

Bu, ML-DSA-87 eklemenin veya Ed25519'u etkinleştirmenin mevcut doğrulayıcı yapılandırmalarını geriye dönük olarak zayıflatamamasını garanti eder: bir v1 doğrulayıcısı, bir v2 profili yayınlandıktan sonra bile bir v1 doğrulayıcısı olarak kalır.

15.3 Tetikleyici koşullar

§15'i şunlardan herhangi biri önerildiğinde normatif duruma yükseltin:

• İkinci sig_alg bayt (Ed25519 etkinleştirme, ML-DSA-87 veya §9 siciline yeni eklenen herhangi bir giriş).
• Üretimde kullanılan ikinci bir drand zinciri.
• İkinci bir dış sarmalayıcı versiyonu.
• Şeffaflık günlüğü güven kökünün bir rotasyonu — LogProfile.anchor_owner adres veya sabitlenmiş makbuz anahtarı açık anahtarı (§16.6). LogProfile §15.2 profil yüzeyine yönetilen bir ilkel olarak katılır: bir dönüş işaretli bir şekilde LogProfile doğrulayıcı güncellemesinde gönderildi (planlanan rotasyonlar gelen → giden üzerindeki çapraz imzayı içerir; ihlal kaynaklı rotasyonlar içermez ve ara hasarı sınırlayan prev-anchor çatalla kontrolüne dayanan bu gönderime güvenir). Şeffaflık günlüğü sürüm boşlukları (LOG_VERSION, ANCHOR_FORMAT) tam olarak §12.5 sarmalayıcı sürümü protokol sürümünden bağımsız olduğu gibi bağımsız kardeşler olarak evrimleşir.

O zamana kadar §15, gelecekteki PR'ların müzakere yüzeyini sıfırdan yeniden tartışmak yerine bilinen bir hedefe karşı inmesi için geçiş şeklini sabitleyen bir yer tutucudur.

16. Şeffaflık günlüğü ve dayanıklılık katmanları (Tasarım — inceleme tamamlandı)

Durum. Bu bölüm uygulandı (W5/UP-B1, Aşamalar 1–8), burada belirtilen üretici ve kök güven kapsamı ile. Tel formatları, özetleme ve doğrulayıcı yolları aktiftir: çekirdek Merkle + canonical-CBOR türleri (qub-core), TypeScript aynası + ANS-104 paketleyici (workers/api/src/crypto/), tek yazarlı LogDO + koordinat anahtarlı R2 düğüm deposu, the /upload log-ekleme denemesi, günlük çapa + bundler-drenaj cron işleri, the GET /api/v1/qub/:tx_id/proof (dahil etme) ve GET /api/v1/log/consistency (RFC 9162) kanıt uç noktaları, taşınan yazılı dahil etme kanıtı .qub paket (§17.5), yerel ANS-104 çapa doğrulayıcısı (tools/qub-verify), ve çift kendi kendine yayınlanan-başlık kancası (§16.6). Başarılı bir /upload her zaman R2-dayanıklıdır ancak yalnızca log ile kaplandığında LOG_DO yapılandırılmış ve satır içi ekleme başarılı olduğunda; ancak o zaman yanıtı iletilir log_seq, receipt, ve anchor_status. Eğer RECEIPT_SK yok veya geçersizse, o makbuzun sig_b64url boş ve inkar edilemezlik sağlamıyor. Mevcut /seal ve anlaşma yayınlama yolları bireysel Arweave işlemlerini zamanlar ancak bir kayıt yaprağı eklemez. Şu anda hiçbir kod bunu gerçekleştirmemektedir /upload ekleme hatasından sonra önerilen yorumun uzlaşması. W5 dış incelemesi tamamlandı: §16.15 tasarım kararlarını ve başlatma kısıtlamalarını kaydeder, ancak bu kısıtlamalar az önce belirtilen üretici kapsamını genişletmez. Üç güven/deployment öğesi engelli durumda kalıyor: (a) özel anchor cüzdanı (ANCHOR_JWK; LogProfile.anchor_owner hala [0xAB; 32] yer tutucu); (b) makbuz imzalama anahtarı ve eşleşen genel anahtar pini (RECEIPT_SK isteğe bağlıdır ve LogProfile.receipt_pubkey şu anda boş); ve (c) self-published-heads GitHub deposu + belirteç (§16.6). Çapa/profil pimleri sağlanana kadar, bağımsız bir doğrulayıcı, tam olarak çapa yapılmış, pimlenmiş bir doğrulamayı iddia etmek yerine kanıt durumunu dürüstçe rapor eder. Tasarım kesinlikle ekleyicidir ve vardır değişiklik yok SealedQub / QubEnvelope kablo formatı.

16.1 Gerekçe ve dayanıklılık katmanları

Mevcut yayın yolları, onayı Arweave doğrulamasından ayırır: bireysel bir işlemi türetir ve imzalar, R2'de eseri ve tam gönderim durumunu saklar, ardından asenkron olarak gönderir. Şeffaflık günlüğü, genel kümenin alt kümesi için bağımsız olarak sabitlenmiş bir sıralama katmanı ekler. /upload istekler ki LogDO ekleme başarılı:

Katmanlar, mevcut ticari planı değil, farklı kanıt ve dayanıklılık özelliklerini açıklar. Mevcut kod, kabul edilen her yayın için hâlâ bireysel bir Arweave işlemi planlamaktadır; T3 yalnızca ücretli bir yükseltme olarak sunulmaz. API anahtarı/hesap kota sınırları ayrı uygulama kontrolleri olarak kalır.

Dayanıklılık dürüstlüğü. T1 yazımı eşzamanlıdır, bu nedenle başarılı bir yanıt, bir Arweave geçidi beklemeye gerek kalmadan uygulama düzeyinde dayanıklılık sağlar. Kendisi bağımsız bir zaman damgası oluşturmaz. Onaylanmış bireysel bir işlem, bloğun zaman üst sınırını sağlar. Tam T2 makbuz demetini taşıyan bir yanıt için, bir sonraki onaylanmış çapa aşağıda açıklanan kayıt kanıtını sağlayabilir. Demet eksikse, bu qub'un zaten şeffaflık kaydında olduğuna dair hiçbir gösterge yoktur. Çapa ve yayın gecikmesi, protokol düzeyinde sayısal bir SLA’ya sahip değildir.

16.2 LogLeaf yapısı (iki taahhüt edilmiş şekil)

Bir günlük girdisi, §3.1 profili altında elle yazılmış kanonik CBOR olarak kodlanan bir LogLeaf'tir (kesin uzunluklu, etiket yok, kayan nokta yok, en kısa biçimli tamsayılar, NFC metin, yoksa atlanan isteğe bağlı alanlar, anahtarlar artan kodlanmış-bayt uzunluğuna sonra bayt-bazında sıralı). §3.1 ayrıştır → yeniden kodla → karşılaştır kanonik koruması, özetlemeden önce kodlama yolunda uygulanır (yalnızca kod çözmede değil), bu nedenle iki uygulama bir tamsayı-genişliği veya anahtar-sırası farkı yoluyla yaprak baytları üzerinde anlaşmazlığa düşemez. Tüm tamsayılar u8 / u64 / i64'tür; tüm özetler 32-baytlık bayt dizgeleridir (bstr[32]). Depolanan bir Arweave işlem kimliği, asla bir base64url metin dizgesi olarak değil, bstr[32] olarak taşınan ham 32-baytlık bir SHA-256 özetidir (§3.3 ile eşleşir).

Yaprağın var bir tarafından seçilen iki şekil kind bayt, çünkü genel yükleme yolu byte-kör'dür: POST /api/v1/upload kasıtlı olarak her iki kabul edilen yük biçimini de opak olarak ele alır ve alır qub_id ve unlock_at sadece güvenilmeyen istemci beyanları olarak. Varsayılan özel yolda, body_hash, drand_round, created_at, ve drand_chain_version ayrıca Worker'ın asla elinde tutmadığı §13 dış sarmalayıcı içinde gizlenmiştir. Tür sistemi ayrıca türeyen bir üretici için doğrulanmış bir şekil tanımlar body_hash / drand_round kendisi. Mevcut /seal rota bu değerlere sahip fakat çağırmıyor LogDO, bu yüzden üretim şu anda yalnızca belirtilen emisyonları yayıyor (0x02) başarılı genel yükleme eklerinden çıkan yapraklar. Bölünme, onaylanmış üreticinin bağlantılıymış gibi yapmadan her taahhüt edilen değeri dürüst tutar:

Bir kind=0x02 yaprağı, kasıtlı olarak ne body_hash ne de drand_round taahhüt eder: qub_id ve unlock_at iddia eden, içerik-adresi chash'teki opak bir şifreli metnin taahhüdünü ve sıralamasını onaylar — düz metnini veya turunu değil. İddia edilen bir qub için düz metin/tur ayakları, günlükten değil, mevcut §11 .qub-paket doğrulamasından gelir (§16.11). drand_chain_version yaprakta değildir (varsayılan yolda sarmalayıcının içindedir); zincir ayrıntısı demirde bulunur (§16.7). Kodlayıcı disiplini: tümü-sıfır bir ref veya chash'i reddedin ve cbor.rs'deki outcome_at > 0 sentinel korumasını yansıtarak, pozitif olmayan unlock_at / received_at'ı reddedin.

16.2.1 Özel-qub körleştirmesi

Günlük, §13 dış sarmalayıcısının önlemek için var olduğu numaralandırma kâhini haline gelmemelidir (§13.1). Özel (sarmalanmış) bir qub için asserted yaprağı, log_blind_secret'in sunucu-tutulan bir gizli olduğu körleştirilmiş tanımlayıcı SHA3-256(qub_id ‖ log_blind_secret)'i taahhüt eder ve body_hash'i atlar. Üçüncü bir taraf böyle bir yaprağı belirli bir qub_id'ye bağlayamaz; teslim URL'sine ve dolayısıyla qub_id'ye sahip olan qub'un sahibi, kendi dahil edilmesini doğrulamak için körleştirmeyi yeniden hesaplayabilir. Kamu bir qub (zaten numaralandırılabilir, §13.8 uyarınca Visibility: public Arweave etiketini zaten taşıyan), ham qub_id'yi taahhüt eder. Bu, bağımsız doğrulanabilirliğin yük taşıyan bir gizlilik değişmezine kasıtlı olarak boyun eğdiği tek yerdir; özel qub'lar için bağımsız bağ chash'tir (§16.9).

log_blind_secret muhafazası (çözüldü — §16.15 Q4). Körleştirme, düz metin gizliliğini değil, yaprak bağlanamazlığını korur (§13 sarmalayıcısı bunu bağımsız olarak tutar). Bir log_blind_secret ele geçirildiğinde, saldırganın zaten elinde tuttuğu veya yeniden inşa edebileceği herhangi bir qub_id için (paketine/URL'sine sahip olduğu her qub, artı düşük-entropili veya kamu herhangi bir qub_id) yaprak ref'ini tek bir özette yeniden hesaplar ve onu bağlar — bu, bilinmeyen bir uzay üzerinde kaba kuvvet değil, bilinen bir popülasyonun doğrudan bağlanmasıdır. log_blind_secret'i diğer sunucu gizlileriyle aynı muhafaza katmanında bir korelasyon/Sybil-derecesi gizli olarak sınıflandırın ve yalnızca ileriye dönük döndürün (bir döndürme, gelecekteki yaprakları yeniden körleştirir; zaten demirlenmiş olanları geriye dönük olarak ayıramaz).

16.3 Yaprak ve düğüm özetlemesi

RFC 6962 §2.1 etki-alanı-ayrılmış özetleme, SHA-256 yerine SHA3-256 ile:

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

Etki-alanı önek baytları 0x02 (girdi zinciri, §16.4) ve 0x03 (STH özeti, §16.6) ayrılmıştır ve bunlardan ayrıktır. Bunlar tek baytlardır ve bu nedenle mevcut 10-baytlık ASCII etki-alanı ayırıcılarıyla (QUB_ID_V2, vb.) çakışamazlar. Ağaç, RFC 6962 sol-dolu dengesiz ağaçtır (her iç bölünme, alt-ağaç yaprak sayısından kesinlikle küçük en büyük ikinin kuvvetinde), bu da dahil edilme ve tutarlılık kanıtlarının tek bir denetim-yolu algoritmasını paylaşmasını sağlar. Referans belirtimi, açık sol/sağ türetme sözde kodunu taşır ve sağ-kenar terfi durumunu — ki bunu 4-yapraklı bir vektör gizler — uygulayan bir ikinin-kuvveti-olmayan (5-yapraklı) test vektörü sabitler.

16.4 Özet zincirleme (dahili)

LogDO, yalnızca çökme tutarlılığı için bir dahili girdi zinciri tutar. Bu asla yayınlanmaz ve asla doğrulayıcıya dönük değildir:

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

Yayınlanan ekleme-yalnızca otorite, operatörün yaprakları sunmaya denk geldiği ham sıra değil, kümülatif Merkle kökü + demiridir (§16.5–16.6): zincir, sunulan herhangi bir sıra için yeniden hesaplanır, bu nedenle yalnızca demirlenmiş kök kanonik konumu sabitler.

16.5 Kümülatif Merkle ağacı ve toplama

İzole edilmiş toplama-başına ağaçlar değil, tüm yapraklar üzerinde seq sırasıyla sürekli büyüyen tek bir RFC 6962 ağacı vardır. (Taşıma-yaprağı-zincirli bir toplama-başına inşa reddedildi: bu gerçek bir önek ilişkisi değildir, bu yüzden "tutarlılık kanıtları" sağlam değildir.) Kümülatif ağaç, gerçek RFC 9162 tutarlılık kanıtları verir ve tek bir yakın demirin herhangi bir eski qub için dahil edilmeyi kanıtlamasını sağlar.

The LogDO Dayanıklı Nesne şudur tek yazar (blockConcurrencyWhile, yansıtma QuotaDO / EntitlementDO) — paylaşılan bir günlüğe ekleme yapmak, paylaşılan durum üzerinde okuma-değiştirme-yazma işlemidir ve bu nedenle ASLA KV üzerinden değil, mutlaka bir DO üzerinden gitmelidir. Bu, ağacın sağ kenar sınırını önbelleğe alır (O(log n) hashes) bu yüzden bir batch'i kapatmak O(batch). A parti birlikte sabitlenmiş yapraklar setidir; uygulanan tetikleyicileri bir tree_size en az ... ilerleme LOG_BATCH_MAX_LEAVES (varsayılan 4096), yaşın çapa batması hızına ulaşması veya açık bir yönetici/cron zorla kapatma. root_i yapraklar üzerindeki kümülatif Merkle Ağacı Özeti 0 .. tree_size_i.

16.6 Arweave demiri aracılığıyla imzalı ağaç başlığı

Arweave demir işlemi, İmzalı Ağaç Başlığı'dır (Signed Tree Head) ve ağaç başlığının kendisi için bir operatör imzasının yerini alır: günlük demir, qub anahtarına ihtiyaç duymaz çünkü Arweave tx owner imzadır. Moat tezi geçerlidir — demirlenmiş kök için yük taşıyan, bir qub-tutulan gizli değil, değişmez alt yapıdır.

Günlük tasarımı, bir sıcak başarılı-ekleme gerektirir makbuz anahtarı (§16.10), sabitlenmiş LogProfile ve karşı imzalı anchor_owner. Mevcut uygulama, o güven kökü sağlama işlemini tamamlamadı: RECEIPT_SK isteğe bağlıdır, eksik/geçersiz bir anahtar sig_b64url: "", ve derlenmiş LogProfile.receipt_pubkey boş. Bu tür bir makbuz ekli yaprağı tanımlayabilir ancak değil iptal edilemez imzalı makbuz. Daha güçlü tasarım iddiası, yalnızca bir doğrulayıcı yayınlama işlemi eşleşen genel anahtarı sabitlediğinde ve anahtar sahibinin buna çapraz imzası olduğunda geçerlidir. Tam makbuz üçlüsü olmayan bir yayın yanıtı, herhangi bir kayıt-kabul iddiası yapmaz; boş bir imza ile olan bir yanıt ise ekleme konumu iddiası yapar ancak imza doğrulama iddiası yapmaz.

SignedTreeHead, kanonik CBOR'dur (anahtarlar kodlanmış uzunluğa göre): size:u64, root:bstr[32], batch:u64, prev:bstr[32] (önceki sth_hash; doğuş = 32 sıfır bayt), log_id:bstr[32], first_seq:u64, anchored_at:i64. Özeti sth_hash = SHA3-256(0x03 || canonical_cbor(SignedTreeHead))'tür.

Sabitlenmiş güven kökü. log_id = SHA3-256("QUB_TLOG_V1" || anchor_owner_address). Uyumlu bir doğrulayıcı, anchor_tx.owner == LogProfile.anchor_owner'ı gerektirmek ZORUNDADIR; burada anchor_owner (ve makbuz-anahtarı açık anahtarı), DrandTimelockProvider::quicknet()'te zaten bulunan quicknet sabitlerinin yanında LogProfile olarak qub_core'a yerleştirilir ve doğrulayıcı ikilisiyle dağıtılır. Doğrulayıcı ayrıca, bir ağ geçidi /raw/ yanıtına güvenmek yerine Arweave tx veri → tx_id bağlamasını yerel olarak doğrulamak ZORUNDADIR. Bu, sahte-cüzdan eşitsizlik (equivocation) açığını kapatır: doğrulayıcı hangi cüzdanı sabitlediğine kadar "Arweave'e demirlenmiş" anlamsızdır.

Döndürme, bir reuse değil, bir §15 yönetişim uzantısıdır (çözüldü — §16.15 Q3). §15.2'nin profil yüzeyi şu anda yalnızca sig_alg'ler / drand zincirleri / sarmalayıcı sürümleri / içerik türlerini sıralar ve §15.3'ün tetikleyicileri bunların hiçbirini listelemez — LogProfile / anchor_owner henüz §15'in yüzeyinde değildir. Bu nedenle döndürme yönetişimi inşa edilmelidir: §15.3 (aşağıda) LogProfile tetikleyicisini ekleyecek şekilde genişletilir ve bir döndürme, bir doğrulayıcı güncellemesinde sevk edilen imzalı bir LogProfile yükseltmesidir. Planlı bir döndürme, giden → gelen çapraz-imza taşır; ele geçirme-kaynaklı bir döndürme bunu yapamaz (giden anahtar tam o anda güvenilmez/erişilemezdir) ve önceki-demir çatallanma kontrolünün (aşağıda) ara dönemde hasarı sınırladığı §15-yönetimli yükseltmeye geri döner.

Çifte anlam pencere (öncelikli güven parametresi). Bir yaprak, kapsama çivisi Arweave olduğunda ancak yanıltmaya karşı dirençli olur.onaylandı. Pencere received_at → anchor confirmation (cadence + Arweave kesinliği, protokol gecikme garantisi olmadan). Güven kökü sağlanmadan önce, mevcut uygulama qub'un operasyonel bütünlüğünü ve mevcut olan imzasız ek meta verileri sağlar; planlanan inkâr edilemezlik garantisini sağlamaz. Tamamlanmış tasarımı tanımlayan üç hesap verebilirlik öğesi vardır (tanık modeli §16.15 Q2'nın çözümüdür):

1. Mühür makbuzu (tedariğe bağlı) — SCT analoğu, bir yüklemenin günlük eklemesi başarılı olduğunda geri döner (§16.10). Sadece sig_b64url boş değil ve eşleşen genel anahtar/çapa-sahibi ilişkisi doğrulayıcıya sabitlenmiştir. Şu anda boş olan üretim profili sabiti bu kararı destekleyemez. Bu kontrol, atlanmış bir makbuz demeti veya imzasız bir makbuz için geçerli değildir.
2. Yayınlanmış monitör metodolojisi + önceki zincir yürüyüşü — demir prev zincir baştan yürünür→başlangıç; bir çatal (birinde iki çapa size farklı ile root, ya da kırık prev) uygunsuz davranışın yayımlanabilir kanıtıdır. Çelişki tespiti açık bir operasyonel taahhüttür, sessiz bir varsayım değil.
3. Çift kendi kendine yayımlanmış başlıklar — her yeni baş {sth_hash, tree_size} qub'e ait özel bir yere gönderilir herkese açık, sadece ekleme yapılan GitHub deposu (yük taşıyan, tahrif edilmediği belli olan kendi kendine yayınlama ayağı), yalnızca en iyi çaba ile doğrulama olarak bir sosyal gönderiyle. Başarısız bir gönderim MUTLAKA sayfa göstermelidir (sessizce başarısız olmamalıdır). Uygulandı (Aşama 8) olarak publishHead çapa kancasına tak (workers/api/src/utils/heads-publish.ts): a PUT içerik API'sine olmadan sha yalnızca ekleme yapılabilir (a 422 başın zaten yayınlandığı anlamına gelir, asla üzerine yazılmaz); katılmalı / dağıtıma kısıtlı PUBLISH_HEAD_GITHUB_{TOKEN,OWNER,REPO} ve depo sağlanana kadar atıl. Bir sert GitHub hatası sayfaları aracılığıyla health_alert kanal ve dayanıklı bir başarısızlık metriğini destekler (m:tlog_publish_head_fail); Arweave çakra kendisi asla yayın başarısızlığında geri dönmez. “Sessiz başarısız olma” bu kalıcı metrik tarafından garanti edilir — operasyonlar buna ilişkin dashboard-uyarısı yapmak ZORUNDADIR — en iyi çaba ile yapılan e-posta sayfası teslim edilemese bile. “İlerlemeye dayalı çakra”dan (cron sadece boyut ilerlediğinde yayınlar) iki dürüst sınırlama ortaya çıkar: geçici bir GitHub hatası bırakır boşluk yayınlanmış başlıklar dizisinde o boyut için — sınırlı, sessiz değil (sayfa yapıyor), ve her başlık bir üst küme ağacı taahhüt ettiği için, §16.9 tutarlılık kanıtı boşluğu kapatır; kritik olarak, bu tutarlılık kanıtı şundan hesaplanır GitHub yüzeyinden değil, güvenilir Arweave bağlantılı ağaç, böylece bir GitHub boşluğu asla doğrulanabilirliği zayıflatmaz. Yayınlanmış-başlık boşluklarını dolduran bir telafi geri doldurma gecikmiş bir geliştirmedir.

Dürüstlüğe bağlı (bağlayıcı kısıtlama). Çünkü qub her iki planlanmış gönderi yüzeyini de kontrol ediyor, bu kendi kendine yayımlanmış, bağımsız olarak doğrulanmamış. Herhangi bir ürün, pazarlama veya hukuki yüzey, kaydın 'bağımsız olarak doğrulanmış' olduğunu iddia edemez. Makbuz/profil/başlı başlıklar sağlandıktan sonra, izin verilen iddia şudur ki Eşdeğerlik tespit edilebilir ve başarıyla imzalanmış bir ek, reddedilemez bir makbuz bırakır. O zamana kadar, bu iddia kullanılamaz. Gerçek bir bağımsız üçüncü taraf tanığı, gelecekteki §15 yönetim güncellemesine ertelenir.

received_at operatör-iddiasıdır ve hiçbir iddia ona dayanamaz — herhangi bir ürün / yasal / API / kanıt-sunma yüzeyinde asla kanıt veya anlaşmazlık teyidi olarak yüzeye çıkarılmaz. Arweave demir blok zamanı T, tek güvensiz zaman damgasıdır ("şu zamana kadar günlüğe alındı" üzerinde bir üst sınır). received_at üzerindeki herhangi bir izleme akıl-sağlığı kontrolü, operatör-kontrollü anchored_at STH alanına karşı değil, T'ye karşı karşılaştırmak ZORUNDADIR; böyle bir kontrol, yalnızca dürüst bir operatörün saat hatasına karşı bir korumadır, kötü niyetli bir operatöre karşı bir hesap verebilirlik kontrolü değildir (§16.15 Q5).

16.7 Demir işlemi biçimi ve tempo

AnchorBundle, §16.8 paketleyicisi aracılığıyla yazılan kanonik-CBOR Arweave işlem gövdesidir: ver:u8, sth:bstr (kanonik SignedTreeHead baytları), prev_anchor:bstr (önceki demir tx kimliği ham baytları; doğuşta atlanır), chain_hash:tstr (yürürlükteki drand zinciri — quicknet) ve demir kendi kendine yeterli olacak şekilde toplamanın yaprak-CBOR akışı seq sırasında: bir izleyici, root'u sıfır qub bağımlılığıyla gövdeden yeniden türetir. (Yaprak akışı yüksek hacimde büyürse, gelecekteki bir revizyon yalnızca bir yaprak aralığını referansla taahhüt edebilir; not edildi, v1'de benimsenmedi.)

Arweave etiketleri kasıtlı olarak numaralandırılabilirdir — özel qub'ların aksine, günlüğün bulunması amaçlanmıştır: App-Name: qub-tlog, Anchor-Format: 1, Log-Id: <hex>, Batch: <n>, Tree-Size: <n>, Root: <hex>, Prev-Anchor: <tx>, Content-Type: application/cbor. Etiketler güvenilmeyen ipuçlarıdır; CBOR gövdesi tek otoritedir.

Kadans: varsayılan olarak günlük, hacimle yeniden gözden geçirildi (boyut tetikleyicisi yük altında etkin tempoyu otomatik olarak kısaltır). Mevcut üretici, ücretli-mühür zorlamalı-çapa kancasını uygulamaz. The çapa cüzdanı adanmış ve düşük hızlı, yükleme cüzdanından ayrı — O MUTLAKA onun olmalıdır kendi JWK (ayrı bir anahtar, yükleme cüzdanında mantıksal bir rol değil) böylece bir yükleme cüzdanı ihlali kökleri sahteleyemez — günlük sert bir kök işlem bütçesi ile. Saklama durumu açıkça ifade edilmiştir: bir sıkı devre kesici ve düşük bakiye ile dar kapsamlı kısayol tuşu, "soğuk" değil — günlük otomatik imzalama yapan bir cüzdan soğuk olamaz ve spesifikasyon da başka türlü davranıyormuş gibi görünmüyor.

16.8 ANS-104 paketleyici

İçeride üretilmiş bir ANS-104 DataItem kodlayıcı ve derin-özet imzalayıcı, kabaca 300 satır, yalnızca Web Crypto, sıfır npm bağımlılığı (her iki Turbo SDK de npm ci --ignore-scripts tedarik-zinciri kapısında başarısız olur). DataItem bayt düzeni:

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

İmzalama, Arweave deepHash'tir — ["dataitem", "1", sig_type, owner, target, anchor, encoded_tags, data] üzerinde özyinelemeli bir SHA-384 özeti (Arweave'in kablo gereksinimi, crypto.subtle.digest("SHA-384")) — ardından cüzdan JWK'si ile crypto.subtle aracılığıyla derin özet üzerinde RSA-PSS; id = base64url(SHA-256(signature)). Buradaki SHA-384, bir qub güven ilkeli değil, yalnızca-Arweave-kablosu bir ilkel olarak karantinaya alınmıştır (§15 çiti kaydeder; qub güven özetlemesi baştan sona SHA3-256'dır).

ANS-104 kod yolu, ertelenmiş geri dönüş/boşaltma mekanizmasını sağlar ve yazar AnchorBundle Veri Öğeleri. Olağan yayın yolu önce tam olarak imzalanmış bir Arweave işlemi oluşturur ve JSON’unu kalıcı bir çıkış kutusunda saklar; doğrudan gönderim gecikme optimizasyonudur ve boşaltma yolu, bundler yedekleme uygulamadan önce aynı işlemi tekrar dener. İmza şeması (çözüldü — §16.15 S8): v1, RSA-PSS ile imzalar (imza türü 1) Mevcut Arweave cüzdanı JWK mekanizmasını yeniden kullanmak (yeni uzun ömürlü anahtar saklama sıfır, "bir daha az gizli" tezini destekliyor); Ed25519 §15 PQ-taşıma yoluna ertelendi.

Elle yazılmış derin özet, W5'teki en yüksek-riskli, en düşük-doğal-kapsamlı koddur, bu nedenle kapılaması pazarlık konusu değildir (§16.15 Q8):

1. Diller arası fikstür tlog_v1.json (Rust + TS, §14.5 wrapper_v1.json deseni), derin-özeti, DataItem baytlarını + kimliğini, yaprak özetlerini, bir 5-yapraklı kökü + denetim yolunu, bir STH özetini, bir dahil edilme kanıtını ve bir tutarlılık kanıtını — hem imzalama hem de doğrulama yönlerinde kapsar (doğrulama yönü önemlidir çünkü §16.6'nın yerel tx → tx_id kontrolü, derin özeti yalnızca yazıcıya değil, her bağımsız doğrulayıcıya çeker).
2. Bir referans ANS-104 paketleyicisi aracılığıyla tek seferlik bir birlikte-çalışabilirlik gidiş-dönüşü, yalnızca statik test verisi olarak tüketilir — asla bir npm çalışma-zamanı bağımlılığı değil (yalnızca-Web-Crypto / kurulum-betiği-yok duruşu geçerlidir).
3. Derin-özet + RSA-PSS yolu, üretimin kullandığı aynı crypto.subtle ilkelleri üzerinden gidiş-dönüş yapmalıdır, böylece içeride üretilmiş kodlayıcı bayt-uyumludur.
4. Süregelen bir paket-sonrası kabul izleyicisi, her demir / yedek DataItem'ın gerçekten Arweave kabulüne ulaştığını bir alarm + devre kesici ile doğrular — çünkü derin özet, Arweave-erişilemezlik yedek kuyruğuna da hizmet eder, bu nedenle sessiz bir gerileme, var olduğu kesin kesinti sırasında o kuyruğu ağ-tarafından-reddedilen öğelerle doldurur.

16.9 Dahil edilme ve tutarlılık kanıtları

Her ikisi de RFC 9162, SHA3-256'dır, kanonik CBOR olarak sunulur.

InclusionProof — GET /api/v1/qub/:tx_id/proof: ver:u8, leaf:bstr (tam yaprak CBOR — doğrulayıcı leaf_hash'i kendisi yeniden hesaplar ve asla sağlanan bir özete güvenmez), 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. Tek bir kesin anahtar listesi, test vektörü ile sabitlenmiş.

Bağımsız doğrulama (qub sunucusu yok, §11'i genişletir):

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

Kanıt-sunma depolaması koordinat-anahtarlı OLMALIDIR (çözüldü — §16.15 Q7, engelleyici önkoşul). Soğuk-yaprak kanıt üretimi, yalnızca R2 denetim materyali, toplama-başına düğüm deltaları değil, mutlak ağaç koordinatı (level, index) ile anahtarlanmış kalıcı bir Merkle-düğüm deposu ise doğruluk açısından nötrdür. Koordinat-anahtarlı bir depo ile, herhangi bir (leaf i, size N) denetim yolu, toplama sınırları arasında yeniden hesaplama olmaksızın O(log N) doğrudan R2 GET'lik bir settir; toplama-anahtarlı bir depo ile değildir, ki bu, bu çözümün kapattığı depolama-düzeni boşluğudur. Yaprak gövdeleri de aynı şekilde seq ile içerik-adreslenebilirdir. Bir W5 test vektörü, doğuş-dönemi bir soğuk yaprağı, LogDO depolaması silinmiş olarak yalnızca R2 + Arweave kullanarak çok-sonraki bir köke karşı kanıtlamak ZORUNDADIR, böylece §16.13'teki geri-kazanım-güvenliği iddiası iddia edilmek yerine desteklenir. O(log N) ardışık R2 GET'ler, yalnızca asenkron kanıt uç noktasına aittir — asla mühürleme sıcak yoluna (§16.10) veya tik-başına bir crona değil.

16.10 R2-öncelikli onay sıralaması

Uygulanan POST /api/v1/upload dizi şudur:

1. Ön yarım kapılar (kimlik doğrulama, doğrulama, idempotans bölme anahtarı) — değişmedi.
2. Tam olarak bireysel Arweave işlemini oluşturun, etiketleyin ve imzalayın. Bu, türetilir tx_id yerel olarak, işlem oluşturma bir ağ geçidinden ödül/sabit metadata alabilir. Bir hazırlık hatası, yine de onaydan önce isteği başarısız kılar.
3. Eşzamanlı olarak seçilen eseri şuraya yaz qub-cache/<tx_id> ve kararlı oluşturma-işlem/outbox kayıtlarını sürdürün. Bunlar dayanıklılık ve yeniden deneme tabanıdır; mutabakat öncesi hatalar 503 döndürür.
4. Ne zaman LOG_DO yapılandırılmış, eşzamanlı olarak denemek LogDO.append(leaf). Tek yazar atar seq, giriş zincirini genişletir ve sınır çizgisini günceller. Ekleme RPC'si sadece bunu yapar; toplu kapatma alarm üzerinde dolaylı yoldan çalışır. Bir ekleme ulaşım/uygulama hatası şu anda başarısızlığa yumuşak: yanıt yine de olmadan başarılı olabilir log_seq, receipt, veya anchor_status. Bir uygulama yorumuna rağmen, bugün itibariyle otomatik sonraki log uzlaştırması yapılandırılmamıştır.
5. Onayı geri gönderin. Dahil edin { log_seq, anchor_status: "pending", receipt } sadece ekleme tamamen başarılı tuple'ı geri döndürdüğünde. receipt.sig_b64url Makbuz imzalayan kişi müsait olmadığında boş olur; müşteriler bu değeri imzalı veya inkar edilemez olarak ALMAMALIDIR. İkiliğin yokluğu sadece kalıcı yayın anlamına gelir, şeffaflık günlüğü kabulü anlamına gelmez.
6. Tam imzalı işlemi göndermek için bir ertelemiş görev kullanın. Başarı durumunda gönderim kutusu kaldırılır; başarısızlık durumunda sınırlı boşaltma zamanlayıcısı için bırakılır ve zaten onaylanmış olanı değiştirmemelidir. tx_id. Geçici metadata ve diğer en iyi çaba yan araçları da ertelenir.

Gecikme sınırı. İstek yolu, ön-yarı yetki/kota çalışmasını, işlem hazırlığını/imzalamayı, dayanıklı R2 yazmalarını ve (yapılandırıldığında) şunu içerir LogDO denemek. < 300 ms tasarım incelemesinde bir protokol garantisi değil, operasyonel bir hedef olarak görünür; mevcut işlem hazırlık adımı bir ağ geçidi meta veri isteği gerçekleştirebilir. Gecikme alarmları ve başlatma kapıları operasyonel kontrol araçlarıdır, doğrulayıcıya sunulabilecek kanıt değildir.

16.11 Güven modeli — yaprak türüne göre kapsamlanan kesin iddia

kind=0x01 (onaylı) için: "Bu içerik — body_hash'le eşleşen gövde, qub_id ile tanımlanan — seq konumunda qub'un ekleme-yalnızca günlüğüne taahhüt edildi ve en geç Arweave blok zamanı T'de var olmuştu; drand turu R = unlock_round(unlock_at)'a kadar kriptografik olarak okunamazdı." Bu, tam {tlock tur bağlama + Merkle dahil edilmesi + demirlenmiş kök} üçlüsüdür.

kind=0x02 (iddia edilen, varsayılan) için: "İçerik-adresi chash olan, qub_id ve unlock_at iddia eden opak bir şifreli metin, seq konumunda ekleme-yalnızca günlüğüne taahhüt edildi ve en geç Arweave blok zamanı T'de var olmuştu." Tur ve gövde ayakları, günlük tarafından değil, mevcut §11 .qub-paket doğrulaması (qub_core::unlock) tarafından sağlanır; günlüğün çıplak bir qub-başına işleme kattığı şey, kurcalamaya karşı kanıt sunan sıralama, güvensiz bir üst-sınır taahhüt zamanı ve eşitsizlik direncidir.

Her iki iddia da §11 uyarınca şunları hariç tutar: sig_alg ≥ 0x01 olmadan yazarlık, niyet ve demir-altı-ayrıntı zamanlama. İkisi de hiçbir iddianın received_at'a dayanmasına izin vermez.

Talep tavanı (bağlayıcı başlatma kısıtı — çözülmüş §16.15 S1). İddia edilen için (kind=0x02) yaprak, yukarıdaki kapsamlı iddiadır tavan herhangi bir ürün, pazarlama, şartlar veya kanıt-rendering yüzeyinin ileri sürebileceği şey. Hiçbir yüzey, günlüğün bir içeriği veya bir byte-gözü kapalı yüklemenin kilit açma turunu kanıtladığını belirtemez veya ima edemez — günlüğün kanıtladığı şey sıralama + opak bir şifre metni için güvenilir olmayan üst sınır taahhüt süresidir. İçerik ve tur kanıtı yalnızca mevcut §11’den gelir .qub-günlük bağımsız paket doğrulaması. Başarılı bir ekleme/alım olmadan yapılan bir yayın, hiçbir günlük talebine sahip değildir.

16.12 Sürümleme ve W3 koordinasyonu

Var hayır SealedQub tel çıkıntısı ve bu nedenle protokol sürümü yükseltmesi yok (§12.2): günlük, mevcut alanlara ve baytlara işlem yapan bir yan araba olduğundan, §12.3 protokol sürümü geçmişine dahil olmaz. W3 opsiyoneldir drand_chain_version elle değmemiş ve tek seçenek olarak kalır SealedQub alan. Bunun yerine günlük, kendi bağımsız versiyon alanlarını tanıtır — LOG_VERSION_1, ANCHOR_FORMAT_1, InclusionProof.ver — §12.5 sarmalayıcı sürüm bağımsızlığını yansıtıyor (sarmalayıcı, protokol sürümünden bağımsız bir sürüm baytı taşır ve günlük sürümleri aynı ayrımı takip eder).

Kanıt teslimi varsayılan olarak çekilir, isteğe bağlı bir yanında-binme ile. Mühürleme anında bir kanıt var olamaz (demir henüz yazılmamıştır), bu nedenle mühürleme-anı .qub paketi kanıt-içermez kalır. W7'nin doğrulayıcısı GET …/proof'u bir kez çeker ya da tamamen-çevrimdışı modda kanıtı Log-Id üzerinde bir Arweave sorgusu aracılığıyla kamu AnchorBundle'dan yeniden inşa eder. .qub paketi (W7), W3'ün drand_chain_version'ıyla aynı "isteğe bağlı, varsayılan olarak atlanan, eklemeli" desenini izleyerek bir isteğe bağlı inclusion_proof üyesi ayırır — mühürlemede yok, soğuk arşiv için demir-sonrası bir yeniden-dışa-aktarımla doldurulur.

16.13 Saklama

LogDO açık kuyruğu, R2 kanıt-sunma alt yapısı, demir devre-kesici sayaçları ve paketleyici yedek kuyruğu için saklama pencereleri docs/DATA-RETENTION.md'de belirtilmiştir. İlke: günlüğün sıcak girdi-başına depolaması (LogDO) demir-sonrası geri-kazanılabilirdir; denetim materyali — koordinat-anahtarlı (level, index) Merkle-düğüm deposu + seq-adresli yaprak gövdeleri (§16.9) + Arweave demirleri — kalıcıdır. Bir soğuk yaprağı DO'dan geri kazanmak, asla yayınlanmış bir kanıtı geçersiz kılmaz, çünkü bir kanıt DO'ya karşı değil, o kalıcı R2 düğüm deposuna ve Arweave demirine karşı çözülür (ve §16.9 silinmiş-DO test vektörü bunu kanıtlar).

16.14 Test vektörleri

W5, diller arası fikstür tlog_v1.json'u (§16.8) artı işlenmiş vektörleri sevk eder: bir kind=0x01 ve bir kind=0x02 yaprağı → leaf_hash; 5-yapraklı kümülatif kök; bir dahil edilme kanıtı; bir tutarlılık kanıtı; bir AnchorBundle; ve bir DataItem kimliği. Bunlar, §14.5 dış-sarmalayıcı vektörlerinin yanında bulunur ve hem Rust (qub-core) hem de TypeScript (Worker) uygulamaları tarafından uygulanır.

16.15 İnceleme Kararları (W5 — çözüldü)

W5 dış incelemesi (karşıt tasarım denetimi + sahibi onayı) tamamlandı. Aşağıdaki her karar kararlaştırılmış olup yukarıdaki §16 metninde yansıtılmıştır; bağlayıcı başlatma kısıtlamaları sonunda yeniden ifade edilir. Uygulama bunlar kapsamında ilerleyebilir.

1. Varsayılan-yol (kind=0x02) yaprak dürüstlüğü — ÇÖZÜLDÜ. Belirtilen şekilde iki yapraklı türü ayırarak gönderin: kind=0x02 hiçbiri taahhüt etmez body_hash ne de drand_round. Hayır *_body_hash bayt-kör yolundaki alan (bu, bütünleyiciler için en okunaklı sahte "doğrulanmış" sinyal olurdu ve zaten paketden §11 tarafından sağlanan bir kolaylıktır). Yap değil log-onaylı qublar için sunucu-mührü gerektirir (bu, Worker üzerinden düz metni zorlayacak ve kripto-parçalama hendeğini yok edecektir). Herhangi bir kendi kendini tanımlayan kısa devre bunu içermelidir .qub doğrulayıcı yeniden hesaplanan alan olarak paket / kanıt zarfı, asla yaprak alanı olarak değil. Sahip onaylı talep tavanı: §16.11.
2. Çifte anlam / eksiklik sorumluluğu — TASARIM ÇÖZÜLDÜ, TEDARİK TAMAMLANMADI. Tasarım, mühür-alma anahtarının takılmasını gerektiriyor LogProfile ve karşı imzalı anchor_owner, ayrıca izleme metodolojisi, önceki zincir yürüyüşü ve çift kendi kendine yayımlanmış başlıklar. Derlenmiş profil ve dağıtım kancaları hâlâ §16.6'da ayrıntılandırıldığı şekilde yer tutucu/opsiyonel durumda, bu nedenle daha güçlü algılanabilir + makbuzlu iddia, bu kapılar kapanana kadar geçerli değildir. Asla bağımsız tanık olarak pazarlanmamalıdır. Gerçek bir üçüncü taraf tanık, §15 yönetişim yükseltmesine ertelenmiştir.
3. Sabitlenmiş demirbaşı sahibi güven kökü + döndürme — ÇÖZÜLDÜ. Benimse LogProfile pim (§16.6); doğrulayıcı kontrol eder anchor_tx.owner == anchor_owner ve tx verilerini → tx_id bağlamasını yerel olarak doğrular. Rotasyon yönetimi bir §15'tir inşa etmek için uzantı (§15.3 tetikleyici eklendi), yeniden kullanım değil; planlanan rotasyonlar çapraz işaret, ödün verici rotasyonlar hasarı sınırlayan çatal kontrolü ile §15 artışına geri düşer.
4. Özel qub yaprağı körlüğü — ÇÖZÜLDÜ. Özel qubs için kör etmeye devam et (ref = SHA3-256(qub_id ‖ log_blind_secret)), çiğ qub_id halka açık qubs için (zaten §16.2.1), chash bağımsız kravat olarak. log_blind_secret bir korelasyon/Sybil-sınıfı sırrıdır, yalnızca ileriye döndür (§16.2.1).
5. received_at — KARAR VERİLDİ. Bunu yaprakta tutun, bağlı ama açıkça kanıt niteliğinde olmayan; hiçbir zaman kanıt veya anlaşmazlık doğrulaması olarak herhangi bir yüzeye çıkmamış. Herhangi bir izleme akıl sağlığı kontrolü, Arweave blok süresine karşı karşılaştırılır T, operatör kontrollünde olan değil anchored_at (§16.6).
6. Katmanlı kanıtlanabilir zamanlama — TASARIM ÇÖZÜMÜ, MEVCUT YÖNLENDİRME DEĞİL. İncelenen tasarım, ankraj-blok zamanlamasını toplu katmana ve tam saat kanıtını ödenmiş T3'e atamakta, önceki için sayılandırılmış bir SLA bulunmamaktadır. Mevcut yönlendirmeler bu ticari ayrımı uygulamış değildir: kabul edilen her yayın için ayrı bir işlem planlamakta ve kayıt kapsamı §16.1/§16.10'da belirtildiği gibi koşullu olarak kalmaktadır. Ürün metni uygulamayı, bu gelecekteki katman ayrımını değil, tanımlamalıdır.
7. İşçiler üzerinde birikimli ağaç — KARARA BAĞLANDI. Tekil kümülatif RFC 9162 ağacı + sınır önbellekli tek-yazıcı LogDO (yaklaşık 1k yazım/sn DO tavanına karşı rahat boşluk; Merkle-of-shard-kökleri parçalama işlemini buna yaklaşana kadar ertele). Koordinat-anahtarlı (level, index) R2 düğüm deposu + silinmiş-DO soğuk-yaprak test vektörü uygulanmıştır (§16.9). < 300 ms protokol sözü değil, tasarım/işletim hedefi olarak kalır (§16.10).
8. ANS-104 imza şeması + derin-hash — ÇÖZÜLDÜ. RSA-PSS (imza türü 1, özel anchor-cüzdan JWK yeniden kullanılıyor); Ed25519 §15 PQ yolu için ertelendi. El yapımı SHA-384 derin hash, her iki yönde çapraz uygulama donanımı üzerinde sınırlandırılmıştır, yalnızca statik referans-bundler uyumluluk kontrolü, paylaşılan-crypto.subtle gidiş-dönüş ve paket sonrası Arweave-kabul izleyicisi (§16.8).

Başlatma kısıtlamalarını bağlama (uygulamaya geçirmek + ürün/hukuk incelemesi):

• Talep tavanı (S1/S6). Hiçbir yüzey, kütüğün kanıtladığını veya iddia edilen bir yaprağın içeriğini veya yuvarlağı açtığını söyleyemez; başarılı bir şekilde sabitlenmiş için izin verilen iddia kind=0x02 yaprak güvensiz üst sınır taahhüt zamanı ile sıralanmış ve müdahaleye karşı kanıtlanabilir şekilde düzenlenir. Makbuz demeti olmayan bir yanıtın hiçbir günlük talebi yoktur. Hiçbir zaman damgası kopyası sayısal bir gecikme garantisi taşımaz.
• Dürüstlüğe tanık olun (Q2). Pazar itibari belirsizliği tespit edilebilir + alındı belgesi mevcut olarak, asla bağımsız olarak tanık olunmuş şekilde değildir.
• Makbuz + çapa tuşları (Q2/Q8). İnkar edilemezlik/bağlantılı doğrulama iddiaları gönderilmeden önce, makbuz açık anahtarını sağla ve derle-pin yap, bunu sağlanan bağlantı sahibi ile çapraz imzala ve bağlantı cüzdanını, yükleme cüzdanından ayrı olarak kendi JWK'si olarak tut.
• Derin karma kapısı (Q8). Her iki yönlü montaj + birlikte çalışabilirlik kontrolü geçene kadar hiçbir çapa veya T3 tx gemisi yok; kabul izleme cihazı hata durumunda sayfa gönderir.
• Depolama önkoşulu (Q7). Koordinat anahtarlı düğüm deposu + silinmiş-DO soğuk-yaprak vektörü, "geri kazanımın hiçbir zaman bir kanıtı geçersiz kılmayacağı" garantisi için ön koşullardır.

17. Taşınabilir Doğrulama Paketi (.qub)

Durum. Bu bölüm uygulandı (W7 / UP-C2): qub_core::export paketi üretir ve ayrıştırır, ve tools/qub-verify çevrimdışı olarak birini doğrulayan halk tarafından kullanılan, kendi başına çalışan bir CLI'dir. §11 ve §16.9 zaten "the"ye atıfta bulunur .qub "bundle" bir bağımsız doğrulayıcının tükettiği birim olarak; bu bölüm, onun baytlarını ve doğrulama adımlarını belirtir. Bu tamamen ekleyicidir — bundle mevcut §11 girdilerini paketler ve zincir üzerindeki veri formatında hiçbir değişiklik yapmaz.

17.1 Amaç

§11, herhangi bir üçüncü tarafın qub işbirliği olmadan bir qub'un kriptografik artefaktını doğrulayabileceğini belirler. The .qub paket bu doğrulamayı yapar taşınabilir ve çevrimdışı: kapalı CBOR'u ve bunu açan drand turu imzasını tek bir kendi kendine yeten nesne içinde paketler, böylece alıcı içerik bütünlüğünü, tur bağlamını ve herhangi bir yazar imzasını doğrulayabilir hiç ağ araması yok (depolama alma yok, canlı drand isteği yok, qub API yok). Bir paket tek başına şifrelenmiş verisinin ne zaman oluşturulduğunu kanıtlamaz; bağımsız olarak doğrulanmış bir depolama işlemi veya sabitlenmiş günlük kanıtı, ayrı bir varlık-zamanı iddiası sağlar (§11, §17.5).

17.2 Paket Biçimi

A QubBundle §3.1 profili altında el yazısı ile yazılmış kanonik CBOR'dur (kesin uzunluk, etiket yok, ondalık yok, en kısa biçimli tam sayılar, NFC metin, mevcut olmadığında isteğe bağlı alanlar atlanır, anahtarlar kodlanmış bayt uzunluğuna göre artan ve ardından bayt bazında sıralanır). Üç 15 karakterlik anahtar sıralaması d < i < s. Çiğ .qub dosya tam olarak bu baytlardan oluşur; URL veya kopyala-yapıştır taşımada aynı baytlar base64url (pad yok) şeklindedir.

drand_round ve drand_chain_id kolaylık projeksiyonlarıdır sealed_qub_cbor, böylece araçlar içindeki CBOR'u ayrıştırmadan bunları okuyabilir. Bunlar oluşturulurken türetilir ve decode üzerinde yeniden kontrol edildi parçalanmış mühürlü qub'a karşı; üst düzey alanı yüküyle uyuşmayan bir demet reddedilir. Kodlayıcı disiplini, kablo formatının geri kalanını yansıtır: boş olanı reddet drand_signature veya arweave_tx_idve her değişken uzunluktaki alanı bağlı.

17.3 Gömülü drand imzasının kanıtladığı şey

Paket, doğrulayıcının bunu almak zorunda kalması yerine drand imzasını taşır. Zaman kilidi şifre çözme (drand zinciri üzerinde tlock, §8) yalnızca ile başarılı olabilir gerçek bağlı tur için işaret feneri imzası—zincirin sadece o tur sona erdiğinde yayınladığı bir değer ve zincirin genel anahtarı altında geçerli bir BLS imzasıdır. Sahte veya yanlış bir imza BLS doğrulamasında veya IBE/AEAD şifre çözmede başarısız olur. Bu nedenle şifresi çözülen bir paket şunu kanıtlar: şifre metni R turuna bağlıdır ve R turu geçmiştir. Doğrulayıcı zinciri tutturur (DrandTimelockProvider::quicknet()) ve §11 yuvarlak-bağlama denetimini uygular, böylece bir paket, şifre metninin bağlı olmadığı bir turu iddia edemez.

Bu bir serbest bırakma koşulu kanıtıdır, bir oluşturma zaman damgası değil. R turundan sonra geçmiş, herkes R için yeni bir şifreli metin oluşturabilir ve zaten halka açık olanı paketleyebilir imza. Bu nedenle paket tek başına kanıt olarak TANIMLANMAMALIDIR R'den önce var olan şifreli metin veya içerik, önce unlock_at, veya herhangi bir olaydan önce.

17.4 Çevrimdışı doğrulama adım adım gösterimi

qub-verify <file.qub> paketten tamamen standart §11 prosedürünü yürütür, sürer qub_core::unlock::unlock sabitlemiş 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.

CLI çıkıyor 0 (doğrulandı), 1 (doğrulama başarısız — hala kilitli, gövde-hash uyuşmazlığı, kırık tur/zincir bağı veya doğrulanamayan bir imza), veya 2 (kullanım / hatalı paket). A --json rapor, otomasyon için aynı kararları içeriyor. Paket kendi içinde bütün olduğundan, doğrulayıcı kılavuzluğu (“qub-core) ve CLI (qub-verify) üçün gereken tek yazılım üçüncü taraf yazılımlardır; her ikisi de kamuya açıktır ve protokolün mevcut doğrulama yolunu tekrar kullanır — özel bir kripto gerekmez.

17.5 Şeffaflık günlüğü ile ilişki

inclusion_proof §16 Merkle dahil etme kanıtı için isteğe bağlı bir slottur. Sadece paket doğrulaması (§17.4) için tamamlanmıştır bütünlük, yuvarlak ciltleme / yuvarlak geçen süre ve isteğe bağlı yazarlık, ancak kasıtlı olarak bağımsız olarak zaman damgalı bir varlık iddiasına sahip değildir. Dolu, tamamen bağlantı doğrulanmış inclusion_proof §16.11’den yaprak türüne özgü taahhüt ve üst sınır zamanını paketi format sürümünü değiştirmeden ekler. Eksik bir kanıt, sadece 'kanıt eklenmemiş' anlamına gelir—'geçersiz' değil ve mutlaka 'bağlanmamış' da değil.

Referans uygulamada yuva artık yazıldı: qub_core::export::QubBundle::inclusion_proof_typed() döndürür Option<InclusionProof> tam §16.9 yapısını taşıyan (yaprak, denetim yolu, sabitlenmiş kök ve AnchorRef) aynı opak CBOR alanı aracılığıyla — paket formatı sürüm yükseltmesi yok. Bağımsız qub-verify CLI bunu kendi aracılığıyla tüketir --anchor bacak ve — çapa cüzdanı sağlanana kadar (§16, Durum) — dolu ama yer tutucu sahibi kanıtını tam olarak çapalanmış-doğrulanmış yerine yalnızca dahil etme olarak bildirir.