Zycord: स्व-प्रमाणित स्टेट ट्रांज़िशन का एक पीयर-टू-पीयर नेटवर्क

Zycord: स्व-प्रमाणित स्टेट ट्रांज़िशन का एक पीयर-टू-पीयर नेटवर्क। Simstoshi द्वारा, v1.0, 2026. प्रत्येक लेनदेन वह स्टेट साथ रखता है जो उसने पढ़ी और जो उसने लिखी, इसलिए उसका सत्यापन उसके बाइट्स का एक शुद्ध फलन है — कोई डिस्क नहीं, कोई इतिहास नहीं, कोई भरोसा नहीं, और समांतरता पर कोई सीमा नहीं।

इस दस्तावेज़ को उद्धृत करें। अभिलेख का संग्रहित, संस्करणित रिकॉर्ड doi:10.5281/zenodo.22167490 है। इस साइट से एक PDF परोसा जाता है, जिसके साथ प्रोजेक्ट कुंजी E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29। नीचे का पाठ वही दस्तावेज़ है, अनभिप्रेत।

1. परिचय#

आज एक ब्लॉकचेन नोड तीन काम करता है जिनमें कुछ भी साझा नहीं है: वह डेटा वितरित करता है, वह गणना सत्यापित करता है, और वह स्टेट बदलता है। डेटा बैंडविड्थ के साथ स्केल करता है। सत्यापन कोर के साथ स्केल करता है: यदि लेनदेन स्वतंत्र रूप से जाँचे जा सकें तो यह अत्यधिक समांतर है। स्टेट परिवर्तन एकमात्र वास्तव में अनुक्रमिक संसाधन है: कहीं न कहीं, लेखन का एक अकेला प्रामाणिक इतिहास मौजूद होना चाहिए।

मौजूदा डिज़ाइन तीनों को उलझा देते हैं। प्रभावी मॉडल में, एक नोड वैश्विक स्टेट रखे बिना किसी लेनदेन का सत्यापन नहीं कर सकता, इसलिए सत्यापन को स्टेट की स्केलिंग सीमाएँ विरासत में मिलती हैं; और चूँकि एक अकेला gas मार्केट तीनों संसाधनों की एक साथ क़ीमत लगाता है, इसलिए एक हस्ताक्षर जाँच उसी नीलामी में एक स्टोरेज लेखन से प्रतिस्पर्धा करती है। हाल की उच्च-प्रदर्शन चेन निष्पादन को नोड के भीतर समांतर करती हैं, पर हर नोड फिर भी सब कुछ दोबारा निष्पादित करता है, और बाध्यकारी अड़चन स्टेट I/O बन जाती है। इसका उत्तर हमेशा और बड़ी मशीनें रहा है, यानी हमेशा और कम नोड।

यह पेपर उल्टा रास्ता लेता है। हम साझा स्टेट के विरुद्ध निष्पादन को समांतर नहीं करते; हम स्टेट को समांतर पथ से पूरी तरह हटा देते हैं। एक लेनदेन एक सर्टिफिकेट (certificate) बन जाता है जो अपने इनपुट और आउटपुट स्वयं साथ रखता है। उसका सत्यापन उसके बाइट्स का एक शुद्ध फलन है। चेन का काम सिकुड़कर सर्टिफिकेट को क्रमित करने और उन पर एक डिटरमिनिस्टिक fold चलाने तक रह जाता है — तुलनाओं और जोड़ों का एक लूप जो प्रति सर्टिफिकेट स्टेट को ठीक एक बार छूता है। टकराव ब्लॉक को अमान्य नहीं करते; वे अलग-अलग सर्टिफिकेट के skip होने का कारण बनते हैं, और हर skip एक bonded underwriter के खाते में डाला जाता है। समवर्तिता रनटाइम पर खोजी नहीं जाती; वह कॉन्ट्रैक्ट लेखक द्वारा, slot दर slot, घोषित की जाती है।

आगे के अनुभाग परिभाषित करते हैं: सर्टिफिकेट (§2), fold (§3), टाइप्ड स्टेट एक्सेस (§4), बीमा अर्थव्यवस्था (§5), एप्लिकेशन sequencers (§6), सेंसरशिप प्रतिरोध (§7), दोहरा fee मार्केट (§8), फ़्रॉड प्रूफ़ और नमूनाकरण की राह (§9), वर्चुअल मशीन (§10), मशीन-रहित नेटिव एसेट (§11), गोपनीय भुगतान (§12), नेटवर्किंग (§13), तीन-Era लॉन्च और उसका treasury (§14), और संदर्भ कार्यान्वयन से मापन (§15)।

2. स्टेट ट्रांज़िशन सर्टिफिकेट#

Zycord में सर्टिफिकेट (certificate) ही एकमात्र लेनदेन प्रकार है:

Certificate {
    reads:   [(slot, access, operand)]   // declared inputs
    writes:  [(slot, op, value)]         // declared outputs
    program: bytes                       // code or native-op reference
    sigs:    [signature]                 // spending authority
    underwriter: (id, sig, seq)          // who insures it (§5)
    ttl:     height                      // valid if committed by this height
    fee:     (seq_gas_bid, par_gas_bid)  // two markets (§8)
}

एक slot (address, word) है। एक सर्टिफिकेट valid है यदि तीन जाँचें पास हों, जिनमें से किसी को भी किसी स्टेट की आवश्यकता नहीं:

1. प्रत्येक sig उन cells को अधिकृत करता है जिन्हें वह खर्च करता है;
2. underwriter हस्ताक्षर (certificate, ttl) पर सुगठित है;
3. घोषित reads के विरुद्ध program को फिर से निष्पादित करने पर ठीक वही writes उत्पन्न होते हैं जो घोषित हैं। हस्ताक्षर canonical होने चाहिए, और यह किसी लाइब्रेरी के अच्छे शिष्टाचार के बजाय एक consensus नियम है। एक सर्टिफिकेट (certificate) की id उसके अधिकृत करने वाले फ़ील्ड्स का हैश है — reads, writes, program, underwriter, ttl, और fee बोलियाँ। हस्ताक्षर उनमें नहीं हैं, और अगला अनुच्छेद बताता है क्यों। उस id से कुंजीबद्ध seen set ही सम्पूर्ण replay रक्षा है। Fee एक अधिकृत करने वाला फ़ील्ड है, relay वरीयता नहीं, और यह भेद मौद्रिक है: एक बोली हस्ताक्षरकर्ता का किसी लागत पर सहमत होना है, इसलिए id के बाहर की बोली वह बोली होगी जिसे रास्ते में कोई भी दोबारा लिख सके — इतनी बढ़ाकर कि base fee के ज़रिए भेजने वाले का शेष जल जाए, या शून्य करके कि सर्टिफिकेट हर ब्लॉक से बाहर रहे। एक सर्टिफिकेट जो चुकाता है वह उसी का हिस्सा है जिसे उसके हस्ताक्षरकर्ता ने अधिकृत किया, और id यही कहती है। Canonicity जो ख़रीदती है वह एक id से सँकरा है और फिर भी एक consensus नियम है: एक ऐसी योजना जो एक हस्ताक्षर के दो encodings स्वीकार करती है, वह एक सर्टिफिकेट के दो exemplars स्वीकार करती है, और दो कार्यान्वयन जो इस पर असहमत हों कि इनमें से कौन सत्यापित होता है, वे एक ऐसे सर्टिफिकेट पर fork कर चुके हैं जिसे उनमें से कोई भी invalid नहीं कह सकता। इसे बंद करने वाला नियम एक वाक्य है: एक ग़ैर-canonical हस्ताक्षर encoding invalid है, और वह कार्यान्वयन जिसका सत्यापक इसे स्वीकार करता है, इस प्रोटोकॉल का कार्यान्वयन नहीं है। ठोस योजनाएँ ऐसे encodings को पहले से ही अस्वीकार करती हैं; इसे लिख देने का कारण यह है कि जो ऐसा नहीं करतीं वे भी लोकप्रिय हैं, और एक स्वतंत्र कार्यान्वयन जो उनमें से किसी को चुन ले, वह इस तरह विचलित होगा कि उसका अपना कोई परीक्षण उसे उजागर नहीं करेगा।

यादृच्छिकीकृत प्रदर्शन अपवाद हैं, और यह अपवाद संरचनात्मक है, encoding का मामला नहीं। एक range proof (§12) यादृच्छिकीकृत है: एक कथन के लिए prover nonces चुनता है, इसलिए एक कथन के असीमित रूप से अनेक valid प्रमाण होते हैं, सभी canonical, और अस्वीकार करने को कोई ग़ैर-canonical encoding है ही नहीं। एक कथन के दो valid प्रमाण एक प्रमाण के दो encodings नहीं हैं; वे दो प्रमाण हैं, और payee — जिसके पास opening है — हमेशा एक नया बना सकता है। इसलिए canonicity उन तक पहुँचती ही नहीं। एक हस्ताक्षर इन्हीं में से एक है, और इसे चूक जाना आसान है क्योंकि यह विदेशी क़िस्मों में से नहीं है। Ed25519 ज्ञान का एक Schnorr प्रमाण है: हस्ताक्षरकर्ता एक nonce चुनता है, और हर nonce उसी संदेश पर एक भिन्न हस्ताक्षर देता है, हर एक valid और हर एक पूर्णतः canonical। डिटरमिनिस्टिक nonce व्युत्पत्ति हस्ताक्षरकर्ताओं के लिए एक नियम है जिसे कोई सत्यापक जाँच नहीं सकता और कोई encoding नियम थोप नहीं सकता, क्योंकि हर nonce बिंदु किसी भी अन्य बिंदु की तरह canonical रूप से encode किया जा सकने वाला बिंदु है। तो एक अधिकृतीकरण के असीमित रूप से अनेक हस्ताक्षर होते हैं, और उन्हें समेटने वाली id के असीमित रूप से अनेक मान होते — हर एक सर्टिफिकेट (certificate) के अपेक्षित हस्ताक्षरकर्ताओं में से किसी एक द्वारा उत्पन्न किया जा सकने वाला, बाक़ियों के हस्ताक्षर बिना छुए साथ ले जाता हुआ, और हर एक अपने अलग ब्लॉक में बिल किया जा सकने वाला। ख़तरे का मॉडल एक प्रमाण के मुक़ाबले सँकरा है और निष्कर्ष वही है: एक प्रमाण को कोई कुंजी न रखने वाला payee फिर से यादृच्छिकीकृत कर सकता है, जबकि दूसरे हस्ताक्षर के लिए वह कुंजी चाहिए जिसकी माँग सर्टिफिकेट पहले से करता है। Id इस खाई को रचना से बंद करती है: वह उसके प्रति प्रतिबद्ध होती है जिसे सर्टिफिकेट अधिकृत करता है और उसके प्रति कभी नहीं जिसे वह मात्र प्रदर्शित करता है, इसलिए हस्ताक्षर और प्रमाण दोनों id के preimage से बाहर यात्रा करते हैं। फिर से हस्ताक्षर करने या फिर से यादृच्छिकीकृत करने पर वही id मिलती है, seen set उस प्रतिलिपि को पकड़ लेता है, और दोनों को साथ ले जाने वाला ब्लॉक invalid है। यह एक सर्टिफिकेट के फ़ील्ड्स को दो क़िस्मों में बाँटता है — अधिकृतीकरण, जिसे id समेटती है और हस्ताक्षर हस्ताक्षरित करते हैं, और साक्ष्य, जिसे कोई नहीं। यह विभाजन गोपनीय भुगतानों की प्रतीक्षा करता §12 का सरोकार नहीं है; यह ब्लॉक 0 से भार वहन करता है, जहाँ एक सर्टिफिकेट जो एकमात्र साक्ष्य साथ रखता है वह उसके हस्ताक्षर हैं। एक सत्यापक समांतर चरण में बाइट्स से साक्ष्य जाँचता है और फिर उसे फेंक देता है; केवल अधिकृतीकरण id, seen set और fold तक बचता है।

यह विभाजन एक दायित्व रचता है जिसे id अब नहीं उठाती, और उसे उत्पादन में खोजे जाने के बजाय यहाँ नाम दिया जाता है। Id के preimage से बाहर का साक्ष्य वह साक्ष्य है जिसे रास्ते में कोई भी बदल सकता है: एक सर्टिफिकेट (certificate) लीजिए, उसके प्रमाण की जगह कचरा रखिए, और प्रसारित कर दीजिए — वही id, अब-invalid exemplar। इससे खुलने वाले दो छिद्रों को दो नियम बंद करते हैं। पहला, एक ब्लॉक उस साक्ष्य के प्रति प्रतिबद्ध होता है जिसे वह साथ ले जाता है। ब्लॉक की सर्टिफिकेट सूची exemplar हैशों की सूची है — प्रति सर्टिफिकेट एक leaf, उसके पूरे encoding पर, साक्ष्य सहित — इसलिए "यह ब्लॉक valid है" उन बाइट्स के बारे में कथन बना रहता है जिन्हें ब्लॉक स्वयं टाँकता है। Id इसका उत्तर देती है कि क्या यह अधिकृतीकरण बिल किया जा चुका है, exemplar हैश इसका कि क्या ये बाइट्स उसे सिद्ध करते हैं, और ये दोनों प्रश्न कभी एक कुंजी साझा नहीं करते। जब तक साक्ष्य encoding से अविभाज्य है, तब तक एक leaf पर्याप्त है, जैसा वह तब तक है जब तक साक्ष्य हस्ताक्षर हैं; जब §12 के प्रमाण उसे अपना एक फ़ील्ड बना देते हैं, तब leaf युग्म (id, evidence hash) बन जाता है, और प्रतिबद्धता वही प्रतिबद्धता है। जो उसे कभी नहीं बनना चाहिए वह है ids की सूची: वह किसी विशेष साक्ष्य के प्रति प्रतिबद्ध ही नहीं होती, और चूँकि सर्टिफिकेट सूची का root एक header फ़ील्ड है और header ही proof-of-work का preimage है, इसलिए साक्ष्य बदलने की तब कोई क़ीमत न होती और किया गया कार्य टिका रहता। यह witness-committed लेनदेनों की नज़ीर है, और इसका अनुसरण उसी कारण से किया गया है जिस कारण उसका आविष्कार हुआ था: वह id जो साक्ष्य को समेटती थी malleable थी, और वह id जो असम्बद्ध साक्ष्य की उपेक्षा करती है अंधी है। दूसरा, relay exemplars से व्यवहार करता है, ids से नहीं: वह नोड जिसे ऐसा exemplar मिले जिसका साक्ष्य सत्यापन में विफल हो, वह उस exemplar को id के प्रति बिना पूर्वाग्रह के फेंक देता है — id चिह्नित नहीं होती, invalid के रूप में cache नहीं होती, और बाद में सत्यापित होने वाला exemplar सामान्य रूप से relay होता है। एक विकृत प्रतिलिपि अपने विकृतकर्ता को उसे भेजने की बैंडविड्थ जितनी पड़ती है और सर्टिफिकेट को कुछ नहीं पड़ती। Proposer का अंधापन बचा रहता है: वह उन exemplars को शामिल करता है जिन्हें उसकी अपनी stateless जाँच ने स्वीकार किया, इसलिए उसे विकृत प्रमाण शामिल करने के लिए उससे अधिक नहीं फुसलाया जा सकता जितना एक ख़राब हस्ताक्षर के लिए, और §3 का प्रतिपादन वही अर्थ रखता है जो रखता था।

Validity सर्टिफिकेट (certificate) के बाइट्स का एक शुद्ध फलन है। कोई भी मशीन इसे जाँच सकती है, एक थ्रेड पूल में, किसी दूसरे कंप्यूटर पर, GPU पर, बिना किसी डेटाबेस के, बिना इतिहास के, और बिना समकालन के। हस्ताक्षर जाँचें सर्टिफिकेटों के आर-पार batch होती हैं; एक ही program के सर्टिफिकेट single-instruction, multiple-thread workloads में batch होते हैं (§6); range proofs (§12) लघुगणकीय सीमांत लागत के साथ batch होते हैं। यही वह गुण है जिस पर इस पेपर की बाक़ी सब चीज़ें टिकी हैं।

निष्पादन के लिए validity पर्याप्त नहीं है। दो valid सर्टिफिकेट एक ही slot के लिए एक ही इनपुट मान घोषित कर सकते हैं; अधिक से अधिक एक ही प्रभावी हो सकता है। इसलिए हम लेनदेन validity की शास्त्रीय धारणा को दो में बाँटते हैं: valid (stateless, समांतर, कोई भी जाँच सकता है) और applicable (stateful, अनुक्रमिक, केवल लेजर में स्थिति से तय)। अगला अनुभाग दूसरे प्रेडिकेट को परिभाषित करता है।

3. लेजर एक fold के रूप में#

एक ब्लॉक में एक header, सर्टिफिकेट (certificate) हैशों की एक क्रमित सूची, और सर्टिफिकेट के शरीर स्वयं होते हैं। शरीर चेन डेटा हैं: एक ब्लॉक तभी valid है जब उसके शरीर उपलब्ध हों (§13)। किसी ब्लॉक का proposer कुछ भी निष्पादित नहीं करता और कोई एप्लिकेशन स्टेट नहीं रखता; वह उन बाइट्स को क्रमित करता है जिनकी validity वह बाइट्स से ही जाँच सकता है। वह पूरी तरह stateless नहीं है, और इस अपवाद को गोल कर देने के बजाय नाम देना उचित है: उसे TTL खिड़की के भीतर देखे गए सर्टिफिकेट ids का सेट रखना होता है, क्योंकि किसी एक को दो बार शामिल करने से ब्लॉक invalid हो जाता है और किसी को भी संयोग से उसमें नहीं फुसलाया जा सकता। वह सेट TTL से बद्ध और prunable है, यही कारण है कि TTL एक consensus पैरामीटर है, relay वरीयता नहीं। प्रस्ताव जानबूझकर सस्ता और भोंदू है, जानबूझकर अंधा नहीं।

चेन की स्टेट क्रमित सर्टिफिकेट (certificate) पर एक fold के रूप में परिभाषित है:

apply_block(S, B):
    assert bodies_available(B)
    assert ∀c: height ≤ c.ttl ∧ ¬seen(c.id)     // an expired or replayed certificate
                                                 // makes the BLOCK invalid: a signature
                                                 // is billable at most once, and never at
                                                 // a position its signer could not avoid
    C ← sort(B.certs, key = (underwriter.id, underwriter.seq, c.id))
    for c in C:
        if leased(S, c):     bill(c, LEASED); mark_seen(c.id, c.ttl); continue  // §7; Era 1 only
        ok ← true
        for (slot, access, x) in c.reads:
            EXACT:  ok ← ok ∧ (S[slot] = x)
            GUARD:  ok ← ok ∧ pred_x(S[slot])
        if ¬ok:              bill(c, STALE);  mark_seen(c.id, c.ttl); continue
        w ← stage(S, c.writes)   // a target whose address is spent, or a delta that would
                                 // over- or underflow, fails HERE — nothing has landed yet
        if w = ⊥:            bill(c, STALE);  mark_seen(c.id, c.ttl); continue
        commit(S, w); settle_fees(c); mark_seen(c.id, c.ttl)

Writes जाँचे जाते हैं, और उनमें से कोई भी उतरने से पहले जाँचे जाते हैं। इस रेखाचित्र के पहले के प्रारूप write सेट को बिना शर्त लागू करते थे, जो ऐसा पढ़ा जाता था मानो एक credit एक खर्च हो चुके cell को पुनर्जीवित कर सके और मानो एक delta wrap कर सके। दोनों में से कुछ भी सच नहीं है और दोनों घातक होते, इसलिए staging चरण अब रेखाचित्र में है, विनिर्देश पर छोड़ा हुआ नहीं। अंकगणित हर जगह जाँचा जाता है जहाँ वह प्रकट होता है: वह delta जो 2²⁵⁶ से आगे या शून्य से नीचे ले जाए, सर्टिफिकेट (certificate) को wrap करने के बजाय skip कर देता है, यही कारण भी है कि §11 की आपूर्ति सीमाएँ असीमित समवर्ती mints के अंतर्गत टिकी रहती हैं। ऐसे पते पर write जिसका अधिकार जलाया जा चुका है, चुपचाप ग़ायब होने के बजाय ज़ोर से विफल होता है — स्थायी spent registry इसी के लिए है, और यही §5 के attribution प्रमेय के एकमात्र अपवाद का स्रोत है।

**leased Era-1 की मशीनरी है और genesis पर मौजूद नहीं है।** इसे यहाँ इसलिए दिखाया गया है क्योंकि यह अनुभाग पूरे प्रोटोकॉल के fold को विनिर्दिष्ट करता है, पर लॉन्च Era में कोई leases नहीं, कोई forced queue नहीं और उनसे बचाव करने को कोई co-signers नहीं, इसलिए यह शाखा genesis binary में अगम्य है — और अगम्य consensus कोड अ-लेखा-परीक्षणीय consensus कोड है, इसलिए उसे भेजा नहीं जाता। एक खुला प्रश्न ढका जाने के बजाय चिह्नित किया जाता है: जैसा लिखा है, LEASED एक सर्टिफिकेट (certificate) को ऐसी स्थिति पर बिल करता है जिसका उसका हस्ताक्षरकर्ता पूर्वानुमान नहीं कर सकता था, और चार पंक्ति ऊपर का प्रतिपादन ठीक यही मना करता है। या तो उस परिणाम पर बिल नहीं होना चाहिए, या उसे ब्लॉक को invalid करना चाहिए। यह चुनाव उस Era का है जो leases लाता है, और इसे यहाँ इसलिए दर्ज किया गया है ताकि वह Era इस विरोधाभास को चुपचाप विरासत में न पा ले।

स्पष्ट रूप से कहने योग्य गुण:

Skip अर्थ है, विफलता नहीं। वह सर्टिफिकेट (certificate) जिसके reads अब नहीं टिकते, skip कर दिया जाता है, उसका skip fee उसके underwriter को बिल किया जाता है (§5), और ब्लॉक valid बना रहता है। समावेशन और अनुप्रयोग भिन्न घटनाएँ हैं। यही proposer को अंधा होने देता है: वह किसी बासी सर्टिफिकेट को शामिल करके कभी invalid ब्लॉक नहीं बना सकता।

डिटरमिनिज़्म। हर नोड एक समान ब्लॉक अनुक्रम से एक समान स्टेट व्युत्पन्न करता है। क्रम कुंजी (underwriter, seq, certificate id) ब्लॉक की सामग्री पर एक पूर्ण क्रम है, इसलिए fold इस बात के प्रति असंवेदनशील है कि एक proposer भिन्न underwriters के सर्टिफिकेट (certificate) को कैसे गूँथता है — और proposer के पास कोई विवेकाधिकार छोड़ता ही नहीं, उन दो सर्टिफिकेटों के बीच भी नहीं जिन्हें एक underwriter ने एक ही seq पर हस्ताक्षरित किया। एक underwriter की अपनी pipeline (seq आरोही) उसी क्रम में कमिट होती है जिसमें उस पर हस्ताक्षर हुए, चाहे proposer ने उसे किसी भी क्रम में जमा किया हो।

प्रति सर्टिफिकेट ठीक एक स्टेट स्पर्श। Fold एक गर्म key-value कार्यकारी सेट पर तुलनाएँ, जोड़ और writes करता है: कोई कोड निष्पादन नहीं, कोई हस्ताक्षर सत्यापन नहीं, कोई पुनःनिष्पादन नहीं। वह सब पहले ही हो चुका, समांतर रूप से, validity जाँच के दौरान।

और कोई elliptic-curve अंकगणित नहीं। गोपनीय भुगतान (§12) Pedersen commitments को slot मानों में रखते हैं, और एक commitment एक curve बिंदु है। योजना homomorphic है और दो commitments का योग सार्थक है, जो fold को उन्हें जोड़ने का न्योता देता है। Fold मना कर देता है। एक बिंदु जोड़ में एक u256 जोड़ के ~1 ns के मुक़ाबले सैकड़ों नैनोसेकंड लगते हैं, और एकमात्र अनुक्रमिक चरण में एक EC संक्रिया वह बजट ख़र्च कर देगी जिसकी यह आर्किटेक्चर रक्षा करती है। Fold केवल commitment बाइट्स को ताज़े cells में संग्रहीत करता है और उनकी समानता की तुलना करता है — दोनों मेमोरी संक्रियाएँ; सारा curve अंकगणित समांतर चरण में या मालिक के wallet में होता है (§12)। यही अनुशासन नीचे hashing पर भी लागू होता है।

क्रिप्टोग्राफी का एक टुकड़ा हटाया नहीं गया है, और इसके विपरीत दावा करना बहुत सुविधाजनक होता: एक सर्टिफिकेट (certificate) की id उसके अधिकृत करने वाले फ़ील्ड्स का हैश है (§2), और seen set उसी id से कुंजीबद्ध है, इसलिए किसी न किसी को उसे गणना करना ही है। मायने यह रखता है कि कहाँ, और उत्तर यह है कि उसे यहाँ होने की ज़रूरत नहीं। Id सर्टिफिकेट के बाइट्स पर निर्भर है और किसी और चीज़ पर नहीं — कोई स्टेट नहीं, कोई क्रम नहीं, कोई स्थिति नहीं — इसलिए उसकी गणना समांतर चरण में हस्ताक्षर जाँचों के साथ-साथ होती है और वह fold में उसी तरह पहुँचाई जाती है जैसे स्वयं सर्टिफिकेट। जो कार्यान्वयन उसे इसके बजाय अनुक्रमिक लूप में फिर से गणना करता है, वह पाएगा कि hashing उस चरण पर हावी है जिसे मेमोरी के बारे में होना चाहिए था, और यह ऐसी ग़लती है जिसका नाम लेना उचित है क्योंकि इसे करना आसान है। हम इस बारे में सटीक होना चाहते हैं कि यहाँ क्या हटाया गया है और क्या नहीं। Fold अब भी पूरी स्टेट पर यादृच्छिक पहुँच करता है, प्रति घोषित slot एक स्पर्श, और एक committing नोड अब भी वह स्टेट रखता है। अनुक्रमिक पथ से जो निकलता है वह वह सब है जो एक पारम्परिक चेन पर उस पहुँच को घेरता है — व्याख्या, हस्ताक्षर जाँचें, hashing, एक Merkleized स्टोर का प्रति-संक्रिया प्रमाणीकरण — ताकि स्टेट एक सपाट तालिका में रह सके और सिस्टम का एकमात्र अनुक्रमिक चरण मेमोरी पर एक कसा हुआ लूप हो। संदर्भ fold दस-कोर x86 डेस्कटॉप पर प्रति कोर प्रति सेकंड 883,000 slot संक्रियाएँ बनाए रखता है (§15), और यही एकमात्र चरण है जो समांतर नहीं होता।

मान समानता, versions नहीं। Applicability घोषित read मानों की तुलना करती है, version काउंटरों की नहीं। चूँकि निष्पादन read सेट का एक शुद्ध फलन है, इसलिए वह slot जो बदला और वापस बदल गया (ABA स्थिति) अब भी applicable है: सर्टिफिकेट (certificate) को अब लागू करना अर्थगत रूप से उसे तब निष्पादित कर देने के समान है। इसलिए यह सिस्टम version-आधारित समवर्तिता नियंत्रण से सख़्ती से कम बार skip करता है। Commitment-मान वाले slots के लिए तुलना commitment की बाइट समानता है: अपारदर्शी, सटीक, और उतनी ही सस्ती, एक बार §4 की canonicity शर्तें लागू कर दी जाएँ।

Replay और एकल बिलिंग। एक सर्टिफिकेट (certificate) की id उसका हैश है जिसे वह अधिकृत करता है और कभी उन हस्ताक्षरों का नहीं जो उस अधिकृतीकरण को प्रदर्शित करते हैं (§2), और लागू हुए और बिल-किए-गए-skip दोनों तरह के सर्टिफिकेट seen चिह्नित होते हैं। यह भेद ही इस नियम को नियम बनाता है: वह हस्ताक्षरकर्ता जो एक शरीर को ताज़े nonce पर फिर से हस्ताक्षरित करता है वही id उत्पन्न करता है, इसलिए seen set उस प्रतिलिपि को बिल करने के बजाय पकड़ लेता है। किसी seen या समाप्त सर्टिफिकेट को शामिल करना ब्लॉक को invalid कर देता है — इसलिए एक हस्ताक्षर अधिक से अधिक एक बार बिल-योग्य है, और केवल उस स्थिति पर जिसे उसके हस्ताक्षरकर्ता ने हस्ताक्षर करके स्वीकारा। इस नियम के बिना, एक block producer दूसरों के सर्टिफिकेट को फिर से शामिल कर सकता या जानबूझकर विलम्बित कर सकता ताकि उनके underwriters का धन जल जाए। TTLs consensus-बद्ध हैं, इसलिए seen set prunable बना रहता है।

4. टाइप्ड स्टेट एक्सेस#

वह fold जो केवल exact reads का समर्थन करता, हर लोकप्रिय कॉन्ट्रैक्ट को क्रमबद्ध कर देता: एक AMM pool को छूते हज़ार सर्टिफिकेट (certificate) एक अनुप्रयोग और 999 skips देते। Zycord का उत्तर यह है कि समवर्तिता कॉन्ट्रैक्ट लेखक द्वारा, प्रति slot, सर्टिफिकेट प्रारूप में ही घोषित की जाती है। तीन एक्सेस अनुशासन हैं:

Exact. SLOAD-शैली: read slot का मान गणना में लौटाता है और सर्टिफिकेट (certificate) को उससे बाँध देता है। मनमाना तर्क; गर्म slots पर टकराव; एप्लिकेशन sequencers का क्षेत्र (§6)।

Guarded delta. सर्टिफिकेट (certificate) slot पर एक प्रेडिकेट का प्रतिपादन करता है — balance ≥ 10 — बिना मान को गणना में पढ़े, और एक चिह्नित delta लिखता है — balance += −10। Fold प्रेडिकेट को वर्तमान स्टेट के विरुद्ध जाँचता है और delta लागू करता है। एक ही slot पर कितने भी guarded debits और credits क्रमविनिमेय हैं: वे किसी भी क्रम में लागू होते हैं, और skip केवल तब होता है जब कोई guard वास्तव में विफल हो (एक असली overdraft), तब नहीं जब balance मात्र बदल गया हो। यह अकेला अनुशासन transfers, आपूर्ति-सीमित mints, allowances, और vault शेयरों को समेटता है, यानी on-chain writes का भारी बहुमत।

Pure delta. बिना guard के एक चिह्नित delta। यह कभी टकरा नहीं सकता और कभी skip नहीं हो सकता। Tips, काउंटर, संचायक, इनाम गणनाएँ।

वह नियम जो मॉडल को ठोस रखता है: guarded मान गणना में नहीं बहने चाहिए। एक assert कुछ नहीं लौटाता; एक delta कुछ नहीं पढ़ता। इसलिए पुनःनिष्पादन घोषित reads का एक शुद्ध फलन बना रहता है, और stateless validity (§2) सुरक्षित रहती है। इस विचार की वंशावली पुरानी और ठोस है: डेटाबेस में escrow लेनदेन, transactional boosting, CRDTs [9][10][11]। पर मौजूदा चेन अधिक से अधिक क्रमविनिमेयता का दोहन एक नोड के scheduler के भीतर करती हैं; Zycord इसे नोडों के बीच समवर्तिता अनुबंध बनाता है, जिसे सर्टिफिकेट (certificate) प्रारूप लागू करता है और बीमा अर्थव्यवस्था मूल्यांकित करती है।

उसी दर्जे का दूसरा नियम, जिसे §12 बाध्य करता है: छिपा मान रखने वाला कोई slot तीसरे पक्ष के guard को स्वीकार नहीं करता। ऐसे balance के विरुद्ध जिसका गुप्त रहना अभीष्ट है, वह guard जिसका परिणाम सार्वजनिक रूप से देखा जा सके — लागू या skip — एक balance oracle है: balance ≥ x जमा कीजिए, fold देखिए, द्विभाजन कीजिए, और log₂(balance) प्रयास commitment खोले बिना ही वह संख्या पढ़ लेते हैं। समाधान संरचनात्मक है, सांख्यिकीय नहीं। छिपा मान केवल one-shot cells में रहता है जिन्हें उनके मालिक का हस्ताक्षर खर्च कर सकता है; guarded-delta अनुशासन, जिसका पूरा मतलब यही है कि अजनबी एक slot को सुरक्षित रूप से छू सकें, उन slots के लिए आरक्षित है जिनके मान सार्वजनिक हैं। इसलिए pull-शैली के भुगतान — allowances, subscriptions, vault sweeps — केवल पारदर्शी पटरी पर मौजूद हैं (§12)।

उस नियम को लागू करने के लिए ज़रूरी है कि fold एक छिपे slot को सार्वजनिक slot से अलग पहचान सके, और सपाट तालिका में वह निरीक्षण से ऐसा नहीं कर सकता: एक संपीड़ित commitment और एक u256 balance दोनों 32 बाइट हैं। इसलिए छिपे-मान वाला cell कोई साधारण cell नहीं है जिसमें संयोग से एक commitment पड़ा हो; वह एक भिन्न cell क़िस्म है, जिसे केवल नेटिव shielded संक्रिया (§12) बनाती है और जो पता-स्थान के एक आरक्षित, व्युत्पन्न-योग्य क्षेत्र में रहता है, ताकि एक slot का अनुशासन उसके पते का फलन हो और बाक़ी सब की तरह बाइट्स से जाँचा जा सके। इसके बिना, एक commitment slot पर लक्षित guarded delta — चूक से या दुर्भावना से — fold से एक u256 को एक curve-बिंदु encoding में जुड़वा देता: अंकगणित जाँचें पास हो जातीं, परिणाम कोई commitment न होता, और cell अ-खर्च-योग्य हो जाता। चुपचाप नष्ट हुआ मान, जिसमें fold में कुछ भी विफल न हो, ठीक वही है जिसे रोकने के लिए §3 का staging चरण मौजूद है, और cell क़िस्म ही वह चीज़ है जो उसे इस उदाहरण को भी रोकने देती है।

दो और प्रारम्भिक अवयव मॉडल को पूरा करते हैं:

Write-once cells. वह पता जो चेन पर कभी प्रकट नहीं हुआ, स्थिति ∅ में है; पहला write उसे stored में ले जाता है; उसकी कुंजी से एक हस्ताक्षर उसे स्थायी रूप से spent में ले जाता है। ताज़े cell में लिखना परिभाषा से ही टकराव-मुक्त है, इसलिए नए व्युत्पन्न पते को भुगतान करना शून्य-प्रतिस्पर्धा वाला तेज़ पथ है। यह नेटवर्क की मिश्रित विरासत है [8]: कॉन्ट्रैक्ट के लिए account-शैली persistent cells, भुगतानों के लिए UTXO-शैली one-shot cells, एक ही लेजर में। किसी spent cell के नीचे के मान तब संहत किए जा सकते हैं जब उसे खर्च करने वाला ब्लॉक reorg horizon से गहरे दफ़्न हो जाए — यह confirmations में एक गहराई है, कोई finality gadget नहीं, क्योंकि लॉन्च Era में प्रतीक्षा करने को कोई finality है ही नहीं। वह registry प्रविष्टि जो पते को spent दर्ज करती है, कभी संहत नहीं होती: वही पते को पुनर्जीवित होने से रोकती है, और वही प्रोटोकॉल की ईमानदार खुली समस्या है, जो हर nullifier-set डिज़ाइन के साथ साझा है। §12 के stealth outputs इसी पटरी पर बिना बदलाव चलते हैं, और registry को ठीक उसी दर से बढ़ाते हैं जिस दर से पारदर्शी भुगतान पहले से बढ़ाते हैं: प्रति spend एक प्रविष्टि, छिपा हो या नहीं।

शून्य अनुपस्थिति है। वह slot जिसमें कभी लिखा ही नहीं गया और वह slot जिसमें शून्य लिखा गया, एक ही slot हैं: शून्य लिखना cell को मिटा देता है, और अनुपस्थित cell पढ़ने पर शून्य मिलता है। यह कार्यान्वयन की सुविधा नहीं बल्कि एक consensus आवश्यकता है, और यह दो तरह से भार वहन करती है। यही एक guard या exact read को 0 नाम लेने देती है बिना यह पूछे कि slot मौजूद है या नहीं — अलग करने को कोई तीसरा उत्तर है ही नहीं। और यही state root को उस स्टेट का फलन बनाए रखती है न कि उस इतिहास का जिसने उसे उत्पन्न किया: यदि एक ख़ाली किया गया cell स्पष्ट शून्य के रूप में टिका रहता, तो भिन्न रास्तों से एक समान balances तक पहुँचे दो नोड भिन्न roots के प्रति प्रतिबद्ध होते, जो बहीखाते से आती चेन विभाजन है।

यह §12 को बाध्य करता है, एक तीखे किनारे के साथ। एक Pedersen commitment vG + rH सामान्यतः शून्य स्ट्रिंग नहीं होता, इसलिए एक छिपा balance अंकगणित से अनुपस्थित बन नहीं जाता और मालिक के सिवा कोई नहीं बता सकता कि वह ख़ाली है; persistent छिपे slots हमेशा के लिए अ-संहत-योग्य होते, जो एक और कारण है कि shielded पटरी केवल one-shot cells की है, जो खर्च होकर मरते हैं — एक ऐसा संक्रमण जिसे देने की ज़रूरत शून्य-अनुपस्थिति-है को कभी पड़ी ही नहीं। किनारा यह है कि v = 0, r = 0 समूह का उदासीन अवयव है, और Ristretto encoding में उदासीन अवयव बत्तीस शून्य बाइट हैं — ठीक वही स्ट्रिंग जिसका अर्थ अनुपस्थित है। एक commitment को कभी deletion से नहीं टकराना चाहिए, इसलिए उदासीन अवयव एक valid commitment नहीं है: shielded संक्रिया उसे प्रवेश पर ही अस्वीकार कर देती है, उन canonical-encoding जाँचों के साथ जिनकी एक curve बिंदु को वैसे भी ज़रूरत है (ग़ैर-canonical क्षेत्र अवयव, torsion घटक), और संदर्भ H एक NUMS बिंदु है जिसकी व्युत्पत्ति प्रकाशित है। "बाइट समानता exact है" (§3) बिंदुओं के बारे में एक दावा तभी है जब ये शर्तें टिकें।

Epoch beacon. Programs को परिवेशी मान (timestamp, height) सीधे नहीं पढ़ने चाहिए; इससे निष्पादन घोषित reads के अलावा किसी और चीज़ का फलन बन जाता। इसके बजाय प्रोटोकॉल प्रति epoch एक बार एक आरक्षित slot में एक epoch beacon लिखता है, और programs उसे किसी भी अन्य slot की तरह पढ़ते हैं, आदर्शतः एक range guard के साथ (epoch ∈ [e, e+2]), जो प्रति-ब्लॉक बासीपन के बिना समय-सजगता देता है।

5. बीमित सर्टिफिकेट: हर टकराव का एक मालिक है#

Skipping मुफ़्त नहीं होनी चाहिए, वरना mempool डूब जाता है: एक हमलावर एक ही इनपुट के विरुद्ध हज़ारों valid सर्टिफिकेट (certificate) प्रकाशित कर सकता, ब्लॉक भर सकता, और एक के लिए भुगतान कर सकता। पर skip हुए सर्टिफिकेट ने भेजने वाले के balance को छुआ ही नहीं, इसलिए भेजने वाले से वसूलने को कुछ है ही नहीं; fee वाला slot ठीक वही बासी इनपुट है। Zycord का उत्तर: कोई सर्टिफिकेट underwriter के बिना मौजूद नहीं है, यानी एक ऐसा पक्ष जिसका bonded धन उसके लिए जवाबदेह है।

Underwritten होने के तीन तरीक़े हैं, एक ही तंत्र के तीन रूप:

1. स्व-बीमित। भेजने वाला किसी अबाधित cell से एक छोटी जमा राशि संलग्न करता है। पहले से कुछ lease नहीं होता: fold जमा राशि को ब्लॉक में सर्टिफिकेट (certificate) की स्थिति पर आरक्षित करता है (§3 का रेखाचित्र इस पाइपिंग को छोड़ देता है), और वह सर्टिफिकेट जो अपनी जमा राशि पहले से ख़र्च हो चुकी स्थिति में अनुप्रयोग तक पहुँचे, drop कर दिया जाता है — बिल नहीं, seen चिह्नित नहीं, ताज़ी जमा राशि के विरुद्ध फिर जमा करने को स्वतंत्र — इसलिए ईमानदार उपयोगकर्ता अपनी ही जमा cell पर दौड़ों में कुछ नहीं खोते। जमा राशि सलामत रहते हुए एक skip उसका एक हिस्सा जला देता है। इसके विपरीत प्रकाशन में कुछ नहीं लगता, इसलिए mempool consensus के बजाय relay नीति से बद्ध है: नोड सीमित करते हैं कि वे प्रति underwriter कितना रखेंगे, वही श्रम-विभाजन जो Bitcoin के बाद से हर mempool में है। यह अनुमति-रहित तल है: कोई भी बिना किसी प्रतिपक्ष के हमेशा लेनदेन कर सकता है। यही लॉन्च Era में एकमात्र मोड भी है (§14), जो genesis को न्यूनतम रखता है। जमा cell सार्वजनिक है और भेजने वाले की है, जो स्व-बीमा को हर उस सर्टिफिकेट पर टँका एक स्थायी पहचानक बना देती है जिस पर वह हस्ताक्षर करती है। पारदर्शी भुगतानों के लिए यह कुछ भी उजागर नहीं करता जो भुगतान पहले से उजागर न करता हो; एक shielded भुगतान (§12) के लिए यह उसी stealth output को नष्ट कर देता है जिसके लिए वह भुगतान करता है, और §12 ठीक इसी कारण co-signing की ओर मुड़ता है।
2. Co-signed. एक bonded underwriter सर्टिफिकेट (certificate) को ताज़ी स्टेट के विरुद्ध जाँचता है, (certificate, ttl, seq) पर co-sign करता है, और skip दायित्व अपने ऊपर लेता है। बदले में वह भेजने वाले से बाहर-बाहर शुल्क ले सकता है, और उसका co-हस्ताक्षर स्वयं एक उत्पाद है: एक पूर्व-पुष्टि जिसके पीछे underwriter की अपनी पूँजी खड़ी है। इस भूमिका में कुछ भी यह देखने की माँग नहीं करता कि सर्टिफिकेट क्या हिलाता है: बासीपन cells का गुण है — जीवित या spent — राशियों का नहीं, इसलिए एक underwriter एक shielded सर्टिफिकेट का मूल्यांकन वैसे ही करता है जैसे एक पारदर्शी का, बिना उसे मान का भरोसा सौंपे।

दो चीज़ें जिन्हें उस वादे में धुँधला नहीं होने देना चाहिए, क्योंकि पेपर उन्हें पहले धुँधला कर चुका है। किसी skip पर प्रोटोकॉल की प्रतिक्रिया skip fee को underwriter की जमा राशि से जला देना है — एक दंड, जो किसी को नहीं चुकाया जाता, और यही किसी को skips कराकर मुनाफ़ा कमाने से रोकता है। भेजने वाले की क्षतिपूर्ति एक अलग लेनदेन है: वह underwriter का व्यावसायिक वादा है, और यह डिज़ाइन उसे अभी एक consensus तंत्र के रूप में विनिर्दिष्ट नहीं करता। उसे ऐसा बनाना शब्दों का मामला नहीं है — इसके लिए co-हस्ताक्षर में घोषित एक नीति मान चाहिए, एक नामित लाभार्थी जो भेजने वाला न हो (वरना उत्पाद बीमा धोखाधड़ी का न्योता है), और चेन पर नज़र रखा गया कुल जोख़िम ताकि एक bond दो बार न बेचा जा सके। जब तक वे मौजूद नहीं, "मेरा bond चुकाता है" एक दावा है जो underwriter करता है और जिसका मूल्य बाज़ार लगाता है, कोई नियम नहीं जिसे fold लागू करता हो, और पेपर यह कह देता है, बजाय इसके कि अस्पष्टता उत्पाद बेच दे।

1. Forced. सेंसरशिप-प्रतिरोध पथ (§7), जो एक उपयोगकर्ता जमा राशि से underwritten है और, विशिष्ट रूप से, लागू होने की गारंटी रखता है। दो तरह के दुर्व्यवहारों के बीच अर्थशास्त्र असममित है, और असमिति ही बात है:

वस्तुनिष्ठ दोष slash किए जाते हैं। यदि एक underwriter दो ऐसे सर्टिफिकेट (certificate) पर co-sign करता है जिनके exact reads टकराते हैं (एक ही slot, एक ही घोषित मान, अतिव्यापी TTLs), तो वे दो हस्ताक्षर equivocation का एक स्वयंपूर्ण, on-chain प्रमाण हैं; कोई भी उन्हें जमा कर सकता है, और bond slash हो जाता है। इसी तरह, वह underwriter जो ऐसे सर्टिफिकेट पर co-sign करता है जो stateless validity में विफल हो (ख़राब हस्ताक्षर, ग़लत निष्पादन), शुद्ध पुनःनिष्पादन से slash हो जाता है: सर्टिफिकेट स्वयं ही fraud proof है (§9)।

व्यक्तिनिष्ठ दोष कभी slash नहीं किए जाते। एक ही slot पर दौड़ते दो भिन्न underwriters ने कोई प्रमाणनीय दोष नहीं किया; fold क्रम में बाद वाला एक छोटा skip fee भरता है, बस इतना ही। धीमे, offline, या अविश्वसनीय underwriters पात्रता और प्रतिष्ठा खोते हैं, धन नहीं। नेटवर्क तब मरते हैं जब विलम्ब ज़ब्ती बन जाता है; Zycord केवल वही ज़ब्त करता है जो बाइट्स से प्रमाणित हो सके।

और बिल उसी पक्ष पर उतरता है जिसका नाम सर्टिफिकेट (certificate) लेता है। इस अनुभाग का शीर्षक एक नारा नहीं बल्कि एक प्रमेय है, और उसे उसके किनारों के साथ कहना उचित है। एक बिल किया गया skip हमेशा ठीक इन तीन में से एक होता है: विफल हो रहा read या write उस पते के अधीन है जिसकी कुंजी ने सर्टिफिकेट पर हस्ताक्षर किया; या वह एक mint है जो उसी asset के घोषित minter के दूसरे mint से दौड़ रहा है, जिसने भी हस्ताक्षर किया; या वह एक one-shot पते को credit है जिसके अपने धारक ने सर्टिफिकेट पर हस्ताक्षर होने के बाद उसे सेवानिवृत्त कर दिया (RETIRE, §11)। जिस पक्ष का नाम सर्टिफिकेट नहीं लेता, वह उसे बिल नहीं करा सकता। केवल तीसरा मामला बिल को कारण से अलग करता है, और वह रचना से ही बद्ध है: केवल one-shot cells ही कभी सेवानिवृत्त किए जा सकते हैं, इसलिए वह payee जो एक persistent पता प्रकाशित करता है कोई सतह प्रस्तुत ही नहीं करता; एक सर्टिफिकेट अधिक से अधिक एक निश्चित संख्या में पते सेवानिवृत्त कर सकता है (§13), जो सीमित करता है कि सेवानिवृत्तियों की एक बौछार कितने उड़ान-में भुगतानों को छू सकती है; और skip fee चुकाया नहीं बल्कि जलाया जाता है, इसलिए उसे भड़काकर कोई मुनाफ़ा नहीं कमाता।

Bond का आकार एक असमिका से तय होता है: एक underwriter का bond उस अधिकतम skip दायित्व से बड़ा होना चाहिए जो वह एक TTL खिड़की के भीतर जमा कर सकता है, और unbonding में fraud-proof खिड़की से अधिक समय लगना चाहिए, ताकि कोई दुर्व्यवहार करके, निकासी करके और ग़ायब न हो सके।

6. एप्लिकेशन sequencers#

Guarded deltas भुगतानों की प्रतिस्पर्धा घोल देते हैं। जो बचता है वह गर्म स्टेट पर exact-read तर्क है — एक order book, एक AMM pool — जहाँ दो ईमानदार underwriters की दौड़ फिर भी skips उत्पन्न करेगी। प्रोटोकॉल का उत्तर है कॉन्ट्रैक्ट को अपना serializer चुनने देना: एक कॉन्ट्रैक्ट चेन पर एक bonded sequencer की कुंजी पंजीकृत कर सकता है, जिसके बाद केवल उसी sequencer द्वारा co-signed सर्टिफिकेट (certificate) कॉन्ट्रैक्ट का exact-read पथ ले सकते हैं।

Sequencer एप्लिकेशन टीम द्वारा चलाया गया एक साधारण सर्वर है — websockets, queues, autoscaling, कोई भी web-2 मशीनरी — और उस पर केवल liveness के लिए भरोसा है, safety के लिए कभी नहीं। वह स्टेट गढ़ नहीं सकता: यदि वह निर्माण के दौरान इनपुट के बारे में झूठ बोले, तो सर्टिफिकेट (certificate) canonical fold के विरुद्ध बस skip हो जाता है, और झूठ उसी के bond को पड़ता है। वह जो देता है वह यह है:

क्रमांकन। वह छोटे TTLs वाले उड़ान-में सर्टिफिकेट (certificate) को slots lease करता है और हर सर्टिफिकेट को पिछले वाले के घोषित outputs पर जोड़ता है (वह अपने co-हस्ताक्षरों को seq से क्रमांकित करता है; fold का पूर्ण क्रम गारंटी देता है कि proposer की फेंटाई के बावजूद उसकी pipeline क्रम में कमिट हो)। गर्म-slot प्रतिस्पर्धा एक off-chain शेड्यूलिंग समस्या बन जाती है, जो चेन को दिखती ही नहीं।

Batch सर्टिफिकेट। एक ही कोड पथ से गुज़रते N लेनदेन एक सर्टिफिकेट (certificate) में मुड़ जाते हैं जिसमें reads/writes समुच्चित होते हैं, आंतरिक मध्यवर्ती writes कट जाते हैं, और N उप-निष्पादन एक अकेले SIMT workload के रूप में सत्यापित होते हैं। यहीं GPU थीसिस ठोस बनती है: जो इकाई क्रमांकन करती है वही इकाई कार्य को उस आकार में पैक भी करती है जो समांतर हार्डवेयर चाहता है, और उसे इसके लिए समांतर gas मार्केट (§8) के ज़रिए भुगतान मिलता है।

परमाण्विक संयोजनीयता। दो एप्लिकेशनों में फैला एक लेनदेन दोनों sequencers द्वारा off-chain मिलकर बनाया जाता है (slot leases पर एक two-phase commit) और चेन पर एक सर्टिफिकेट (certificate) के रूप में उतरता है जिस पर दोनों co-हस्ताक्षर हैं, रचना से परमाण्विक। पार-एप्लिकेशन समन्वय वहाँ होता है जहाँ समन्वय सस्ता है; चेन केवल परिणाम देखती है।

ईमानदार प्रकटीकरण: एक sequencer अपने एप्लिकेशन का order flow सबसे पहले देखता है और इसलिए उस एप्लिकेशन के MEV का स्वाभाविक स्थल है। Zycord सौदे को स्पष्ट कर देता है: एप्लिकेशन अपना MEV स्वयं पकड़ता है, बजाय इसके कि उसे block proposers को रिसने दे, और §7 उससे निहित शक्ति को सीमित करता है। वही forced पथ जो निकास की गारंटी देता है, निष्कर्षण को अनुशासित भी करता है: वह उपयोगकर्ता जिसे किसी sequencer का बर्ताव पसंद नहीं, वह उसे पूरी तरह किनारे से घुमाकर निकल सकता है, केवल विलम्ब चुकाकर।

7. गारंटीशुदा अनुप्रयोग के साथ बलात् समावेशन#

वह कॉन्ट्रैक्ट जिसका एकमात्र दरवाज़ा उसका sequencer है, यदि sequencer सेंसर करे तो वह एक जेल है। इसलिए हर उपयोगकर्ता के पास एक धीमा पथ है जिसे किसी की अनुमति नहीं चाहिए:

एक उपयोगकर्ता (या कोई भी relayer) सार्वजनिक fold से स्टेट पुनर्निर्मित करता है, एक सर्टिफिकेट (certificate) बनाता है, एक जमा राशि संलग्न करता है, और उसे forced queue में जमा करता है। Proposers को queue में पड़े सर्टिफिकेट F ब्लॉकों के भीतर शामिल करने होते हैं (§13)। उसकी समावेशन स्थिति पर, fold उसके reads को वर्तमान स्टेट के विरुद्ध जाँचता है; यदि वे टिकें, तो fold उसके slots पर एक डिटरमिनिस्टिक lease देता है और अनुप्रयोग को D ब्लॉक आगे अनुसूचित करता है। Lease के दौरान, उन slots को छूते co-signed सर्टिफिकेट उसके बाद क्रमित होते हैं। इसलिए forced सर्टिफिकेट skip नहीं किया जा सकता: प्रवेश का अर्थ अनुप्रयोग है।

रियायत अवधि D ईमानदार sequencer की उड़ान-में pipeline के लिए है — उसका वह हिस्सा जो leased slots को छूता नहीं। जो कुछ भी उन्हें छूता है वह forced सर्टिफिकेट (certificate) के बाद क्रमित होता है, co-signed और स्व-बीमित दोनों समान रूप से, और यही "skip नहीं किया जा सकता" को आकांक्षा के बजाय सत्य बनाता है: वह सर्टिफिकेट जिसके reads पूरी रियायत अवधि तक संरक्षित हैं, उस दौरान बासी नहीं हो सकता। चूँकि writes घोषित होते हैं, अनुप्रयोग-पश्चात स्टेट पूर्वानुमेय है, इसलिए एक sequencer एक अ-लागू forced सर्टिफिकेट के ऊपर निश्चितता के साथ जोड़ता चला जाता है।

एक lease केवल उन slots को ढँक सकता है जिन पर सर्टिफिकेट (certificate) का अधिकार है। यह एक बाध्यता है जो तंत्र मुफ़्त में नहीं देता और जिसके बिना बाक़ी डिज़ाइन टिक नहीं पाता। एक read घोषित करने के लिए कोई हस्ताक्षर नहीं चाहिए — केवल writes अधिकृतीकरण व्युत्पन्न करते हैं — इसलिए इस नियम के बिना कोई भी किसी और के slots पर reads घोषित करता हुआ एक forced सर्टिफिकेट queue कर सकता और उन्हें एक जमा राशि की क़ीमत पर D ब्लॉकों के लिए जमा कर सकता। प्रति-कॉन्ट्रैक्ट कोटा भी उसे नहीं बाँधता, क्योंकि नेटिव भुगतान किसी कॉन्ट्रैक्ट के नहीं होते। इसलिए एक lease केवल उन slots पर स्वीकार्य है जिन पर सर्टिफिकेट को लिखने का हक़ है, जो वही अधिकार परीक्षण है जिसे fold पहले से लागू करता है, बस एक क़दम पहले प्रयुक्त।

और भी grief-रोधी सीमाएँ: एक प्रति-कॉन्ट्रैक्ट, प्रति-epoch कोटा; एक जमा राशि जो थोपी गई लागत को ढँके; leased slots मुक्त होने तक और forced प्रविष्टियाँ अस्वीकार करते हैं।

दो परिणाम इसे एक विशेषता से उठाकर उत्तरजीविता तंत्र बना देते हैं। पहला, सेंसरशिप उलट जाती है: वह सेंसर करने वाले को पड़ती है (खोई हुई fees, किनारे से घूमते उपयोगकर्ता) और नेटवर्क को कुछ नहीं पड़ती। दूसरा, वह कॉन्ट्रैक्ट जिसका sequencer ग़ायब हो जाए — या वह चेन जिसका पूरा underwriter वर्ग हमले में हो — forced-only मोड में उतर आती है: धीमी, महँगी, और ज़िंदा। कोई स्टेट कभी अनाथ नहीं होती, और कोई संचालक safety के लिए भार-वाहक नहीं है। अपने संस्थापक से अधिक जीने के लिए बनाए गए नेटवर्क के लिए, यही वह गुण है जो मायने रखता है।

8. दो मार्केट: अनुक्रमिक और समांतर gas#

एक चेन भिन्न स्केलेबिलिटी वर्गों के तीन संसाधन खपाती है — डेटा, सत्यापन, परिवर्तन — और उन्हें एक मार्केट में मूल्यांकित करने का अर्थ है कि एक zero-knowledge प्रमाण का सत्यापन नीलामी में एक स्टोरेज लेखन से प्रतिस्पर्धा करे। Zycord fee को दो स्वतंत्र मार्केट में बाँट देता है:

अनुक्रमिक gas fold संक्रियाओं का मूल्य लगाता है: read जाँचें, writes, leases। यही दुर्लभ संसाधन है, वह एकमात्र लूप जिसे हर नोड क्रम में चलाता है, और उसका मूल्य तदनुसार लगाया जाता है।

समांतर gas सत्यापन का मूल्य लगाता है: हस्ताक्षर जाँचें, पुनःनिष्पादन इकाइयाँ, बाइट्स, और भारी precompiles (प्रमाण सत्यापन, हस्ताक्षर समुच्चयन, post-quantum योजनाएँ)। यह प्रचुर है, इसकी आपूर्ति नेटवर्क में जुड़ते हर कोर और GPU के साथ बढ़ती है, और इसकी ब्लॉक छत ऊँची और सस्ती रखी गई है।

दोनों मार्केट का आकार EIP-1559 वाला है [15], हर एक अपनी इकाई में: base fee जला दी जाती है और priority fee ब्लॉक के producer को मिलती है — उन सर्टिफिकेट (certificate) पर जो लागू होते हैं, और केवल उन्हीं पर। Skip हुए सर्टिफिकेट की fee पूरी तरह जला दी जाती है और किसी को नहीं मिलती, और यह fee अनुसूची का कोई ब्योरा नहीं बल्कि पूरे आर्थिक मॉडल का भार-वाहक नियम है। यदि एक skip tip देता, तो वह पक्ष जो तय करता है कि ब्लॉक में क्या हो, उसे दूसरों की विफलताएँ सजाने का भुगतान मिलता, और कमाई का सबसे सस्ता तरीक़ा काम शामिल करने के बजाय skips की खेती करना होता। जलाना इसे उलट देता है: एक skip छत की जगह खाता है और कुछ नहीं देता, इसलिए राजस्व अधिकतम करता producer अनुप्रयोग अधिकतम कर रहा होता है, और skips कराने के प्रति महज़ उदासीन नहीं बल्कि सक्रिय रूप से उसके ख़िलाफ़ होता है। अनुक्रमिक base fee जलाना उस एकमात्र दुर्लभ लूप की भीड़भाड़ को अपस्फीतिकारी बना देता है (§14.2)। समांतर base fee जलाना proposer को इस बारे में उदासीन रखता है कि कौन से भारी सर्टिफिकेट सस्ती लेन भरें, इसलिए सत्यापन-लेन की प्राथमिकता खाते के बाहर बेची नहीं जा सकती। यह विभाजन बहुआयामी fee डिज़ाइनों की दिशा का अनुसरण करता है [18], जिसे पूरी तरह अलग मार्केट तक ले जाया गया है। जो कोई भी मार्केट तय नहीं करता वह यह है कि दुर्लभ संसाधन कितना होना चाहिए; वह एक छत है, और §8.1 उसे हिलाने वाला नियम देता है।

परिणाम वह डिज़ाइन लक्ष्य है जो एक अपरिवर्ती के रूप में कहा गया है: भारी क्रिप्टोग्राफी नेटवर्क को प्रभावित नहीं करती, आर्थिक रचना से। वह सर्टिफिकेट (certificate) जो एक बड़ा प्रमाण सत्यापित करता है पर दो slots लिखता है, लगभग सब कुछ सस्ते मार्केट में चुकाता है। Zycord इस तरह उस निपटान परत के रूप में स्थापित होता है जहाँ वे क्रिप्टोग्राफ़िक प्रोटोकॉल किफ़ायती हैं जो एकल-मार्केट चेन के लिए बहुत भारी हैं। वही मार्केट sequencers को काम को आकार देने का भुगतान करता है: एक sequencer N लेनदेनों को एक batch सर्टिफिकेट में समुच्चित करता है, उसके लिए एक समांतर बोली चुकाता है, और अपने उपयोगकर्ताओं से N के लिए वसूलता है — यह अंतर काम को SIMT-आकार देने की fee है (§6)।

8.1 लचीली अनुक्रमिक छत#

एक fee मार्केट दुर्लभता का मूल्य लगाता है; वह यह तय नहीं करता कि दुर्लभता कितनी होनी चाहिए। उस प्रश्न के पहले के दो उत्तर दोनों विफल हुए, उलटी दिशाओं में। एक निश्चित छत अपनाव को ऐसी नीलामी बना देती है जिसे उपयोगकर्ता हारते हैं: जब Bitcoin के ब्लॉक भरे, fees $50 पार कर गईं और साधारण भुगतान बस चेन से बाहर मूल्यांकित हो गए, केवल उसके लाभ के लिए जो जगह बेचता था। बिना माँग के खुली छत दूसरी तरफ़ विफल होती है: उसके बड़े-ब्लॉक forks ने वह क्षमता ख़रीदी जिसे किसी ने इस्तेमाल नहीं किया और उसका दाम सुरक्षा में चुकाया, क्योंकि fees आयतन से आती हैं, जगह से नहीं। इसलिए Zycord की छत न निश्चित है न मतदान से तय — वह नेटवर्क जिसका लेखक उसे fork करने के लिए वहाँ नहीं होगा, नियमित वृद्धि को एक शासन घटना नहीं मान सकता, और एक मतदान एक हत्था है: miners आपूर्ति सीमित करने से मुनाफ़ा कमाते हैं, बड़े संचालक उसे वहाँ तक बढ़ाने से जहाँ तक छोटे नोड चल न सकें। छत मापी गई माँग का एक consensus फलन है, genesis में ब्लॉक 0 से, जिसे कोई नहीं हिलाता।

इस नियम के तीन भाग हैं, प्रति समय-पैमाना एक। एक ब्लॉक के भीतर, हर मार्केट का एक लक्ष्य T और एक कठोर लचीली सीमा 2T होती है; base fee प्रति ब्लॉक एक बद्ध अंश से सन्तुलन की ओर क़दम बढ़ाती है, §8 के EIP-1559 आकार में — बद्ध इसलिए क्योंकि अबद्ध समायोजन अभिसरित होने के बजाय दोलन करता है, यह ज्ञात है। Epochs के आर-पार, अनुक्रमिक लक्ष्य माँग का अनुसरण करता है: T ← clamp(2·median_applied(e), T − T/Δ, T + T/Γ), जिसका तल उसका genesis मान है — जहाँ median_applied केवल लागू सर्टिफिकेट (certificate) पर अनुक्रमिक gas गिनता है। Skip हुए सर्टिफिकेट अपनी fees जला देते हैं और कुछ दर्ज नहीं करते, इसलिए छत उठाने का एकमात्र तरीक़ा अनुप्रयोग जीतना है: निरंतर, ग़ैर-टकरावी, base-fee-जलाता उपयोग। वृद्धि को बलपूर्वक कराने में एक हमलावर को ठीक उतना पड़ता है जितना जैविक अपनाव में बाक़ी सबको पड़ता है, यानी तंत्र उन्हें अलग नहीं कर सकता और उसे इसकी ज़रूरत भी नहीं। वृद्धि आगे एक epoch स्वास्थ्य संकेत पर निर्भर है — प्रतिस्पर्धी headers की देखी गई दर एक सीमा के नीचे रहे (Era 0), checkpoints समय पर अंतिम हों (Era 1 से आगे) — इसलिए क्षमता कभी उससे आगे नहीं निकलती जितना प्रसार प्रमाणतः ढोता है। एक बासी ब्लॉक ठीक वही घटना है जिसे चेन दर्ज नहीं करती, इसलिए यह संकेत एकमात्र ईमानदार तरीक़े से आयातित होता है: headers हाल के प्रतिस्पर्धी headers को उद्धृत कर सकते हैं, बिना भुगतान के; उद्धृत करने के लिए असली proof of work चाहिए, जबकि संकेत दबाने के लिए क़रीब-क़रीब हर proposer को वे उद्धरण छोड़ने होंगे जिन्हें कोई एक ईमानदार proposer बहाल कर देता है। यह असमिति द्वार को सावधानी की ओर झुकाती है, जो वही दिशा है जिस ओर एक द्वार को झुकना चाहिए। प्रति ब्लॉक, एक burst वाल्व: एक proposer 2T से आगे 4T तक जा सकता है, और जो ब्लॉक उसे श्रेय देता है उसे वह वर्गानुपाती रूप से गँवाता है — उसका सब्सिडी हिस्सा और ब्लॉक की fees, §14.2 की अनुसूची के विरुद्ध, एक स्थायी कमी के रूप में जो किसी को पुनर्निर्देशित नहीं होती — दंड कुल अनुक्रमिक gas पर आँका जाता है, लागू और skip दोनों समान रूप से, ताकि अतिरेक को छूट पर गढ़े गए टकराव से न भरा जा सके। आधार producer का राजस्व है, अकेली उसकी सब्सिडी नहीं, क्योंकि दोनों साथ क्षय नहीं होते: सब्सिडी §14.2 के वक्र पर अपने genesis मान के लगभग 1.6 % तक गिर जाती है जबकि वह fee राजस्व जिसके लिए एक burst ख़रीदा जाता है, बिलकुल नहीं गिरता, इसलिए अकेली सब्सिडी में अंकित एक निवारक ठीक वहीं निवारण करना बंद कर देता है जहाँ अवसर सबसे बड़ा है। एक स्थायी गुण का मूल्य किसी ऐसी चीज़ में लगना चाहिए जो लाभ का पीछा करे, और यही तर्क EIP-1559 एक शुल्क को उस मूल्य से जोड़ने के लिए देता है जो हेरफेर कमाता है। Genesis पर इससे लगभग कुछ नहीं बदलता, क्योंकि fees शून्य के क़रीब हैं। §14.1 का treasury हिस्सा अ-घटी सब्सिडी से लिया जाता है और कभी नहीं गँवाया जाता, क्योंकि burst करना producer का चुनाव है और treasury उसका पक्षकार नहीं है। असली उछाल तुरंत रास्ता ख़रीदते हैं और epoch नियंत्रक को सूचित करते हैं; spam एक दंड ख़रीदता है। नज़ीर Monero का penalty-median तंत्र है [19], जिसकी प्रलेखित रुकावट — जब काम की सामान्य इकाई median के पास पहुँचे तो वृद्धि का जम जाना — रचना से टाली गई है, क्योंकि batch सर्टिफिकेट (§6) सामान्य इकाई को लक्ष्य के मुक़ाबले छोटा रखते हैं, और दर सीमाएँ adaptive-limit वंशावली का अनुसरण करती हैं [20]। समांतर छत को इस सावधानी की कोई ज़रूरत नहीं: वह अनुक्रमिक लक्ष्य के एक निश्चित ऊँचे गुणज के रूप में टाँकी गई है और उसकी वृद्धि विरासत में पाती है, जो §8 का अपरिवर्ती क्षमता के रूप में दोहराया गया है।

इस रस्साकशी को तंत्र से पढ़ लीजिए। उपयोगकर्ता की fee तल की ओर खिंचती है, क्योंकि निरंतर भीड़भाड़, परिभाषा से, वही संकेत है जो छत उठाता है और उसे वापस नीचे लाता है — स्थायी नीलामी वाला Bitcoin सन्तुलन अगम्य है। Producer को नेटवर्क के युवा रहते सब्सिडी से भुगतान मिलता है और परिपक्वता पर आयतन से, दुर्लभता से कभी नहीं; burn हर भीड़भाड़ प्रसंग को उसी coin में जोड़ता है जो producer के पास है, और §8 पहले ही अनुप्रयोग को, बहिष्करण को नहीं, राजस्व-अधिकतमकारी रणनीति बना चुका है। एक ईमानदारी, दो बार: लचीलापन केवल इतनी गारंटी देता है कि क्षमता कभी वह कारण न बने जिससे अपनाव रुके — वह कोई माँग गढ़ता नहीं, जैसा बड़े-ब्लॉक forks ने साबित किया — और बढ़ती छत स्टेट को बढ़ने देती है, यही कारण है कि ताज़े-slot writes का अनुक्रमिक gas में deltas से ऊँचा मूल्य लगता है: जिस सपाट तालिका में fold रहता है, वह उस छत से तेज़ नहीं फैलती जो उसे खिलाती है। इससे एक अंशांकन नियम निकलता है और उसे इसलिए कहा जाता है क्योंकि उसका उल्लंघन चुपचाप होता है: अनुक्रमिक लक्ष्य और बाइट छत का genesis अनुपात उस ट्रैफ़िक के घनत्व से नीचे बैठना चाहिए जिसके लिए नेटवर्क बना है, ताकि साधारण भुगतानों से भरा ब्लॉक base fee गिराने के बजाय उठाए। वह मार्केट जो अपने ही डिज़ाइन भार पर उल्टा प्रतिक्रिया करे, किसी चीज़ का मूल्य नहीं लगाता, और यह अनुपात freeze से पहले मापे गए ट्रैफ़िक से तय किया जाता है।

Eras के आर-पार क्षमता। सर्टिफिकेट (certificate)-गणना और बाइट छतें अनुक्रमिक लक्ष्य के साथ स्केल करती हैं, न कि उसके बग़ल में स्थिर खड़ी रहती हैं: genesis पर तीनों एक-दूसरे के दुगुने के भीतर बँधती हैं, इसलिए एक निश्चित छत एक ही दुगुनेपन के बाद असली सीमा बन जाती और लचीली को सजावटी छोड़ देती। उनके पीछे स्थैतिक क्षमताएँ खड़ी हैं: वह सर्टिफिकेट-सूची चौड़ाई जो ब्लॉक की merkle गहराई तय करती है, और वह बाइट क्षमता जहाँ तक एक ब्लॉक पहुँच सकता है, उसके नीचे के परिवहन स्थिरांकों के साथ — एक ब्लॉक टुकड़ों में यात्रा करता है, इसलिए कोई एकल नेटवर्क संदेश ब्लॉक को नहीं बाँधता। सूची चौड़ाई genesis पर पूरे वक्र के लिए आकारित है (2²⁵ सर्टिफिकेट; उसे बाद में फिर से टाँकने से एक ही चेन में दो merkle चौड़ाइयाँ आ जातीं, और आभासी padding उस अतिरिक्त जगह को मुफ़्त बना देती है)। बाइट क्षमता लॉन्च नेटवर्क के लिए आकारित है और era सीमाओं पर फिर से टाँकी जाती है — जो पहले से ही hard forks हैं (§14) — उस प्रसार के विरुद्ध जिसे स्वास्थ्य द्वार ने मापा है; कभी किसी era के भीतर नहीं, कभी मतदान से नहीं। यह सीढ़ी जिस वक्र की सेवा करती है वह Γ से निकलता है: लक्ष्य पूरे स्वस्थ ब्लॉकों के प्रति वर्ष अधिक से अधिक 2× चक्रवृद्धि होता है, इसलिए ~90 लागू सर्टिफिकेट प्रति सेकंड की genesis छत (प्रति 30-सेकंड अंतराल एक §15 ब्लॉक) निरंतर माँग के सात वर्षों में ~11,000 प्रति सेकंड तक पहुँचती है, दस में ~90,000, और चौदह से कम में वह ~1.1 मिलियन प्रति सेकंड जिसे 2²⁵ सूची चौड़ाई तय करती है — वह एकमात्र दीवार जिसे कोई era नहीं हिलाता, और इसलिए सीढ़ी का अंत, उसका कोई डंडा नहीं। इकाई सर्टिफिकेट है, भुगतान नहीं: एक सर्टिफिकेट एक भुगतान ढोता है, या वे N जिन्हें एक sequencer ने उसमें batch किया (§6), इसलिए हर आँकड़ा लेनदेनों पर एक तल है, उनके बारे में कोई दावा नहीं। शर्तें ठीक तीन हैं, हर एक ऊपर पहले से एक तंत्र: माँग को पूरे ब्लॉक बनाए रखने होंगे, क्योंकि लागू gas ही एकमात्र इनपुट है जो T उठाता है; प्रसार को स्वास्थ्य द्वार खुला रखना होगा, क्योंकि जिस epoch में वह बंद हो उस epoch वृद्धि रोक ली जाती है; और फिर-से-टाँकने eras पर उतरने होंगे, क्योंकि उनके बीच बाइट क्षमता ही दीवार है। गणना कोई शर्त नहीं है — fold एक अकेले मापे गए कोर पर वक्र का दूर वाला सिरा पार कर लेता है (§15), और सत्यापन उस हार्डवेयर के साथ स्केल करता है जो नेटवर्क का अपना नहीं है (§2)। बैंडविड्थ शर्त है: शरीर चेन डेटा हैं (§13) और नमूनाकरण (§9) सत्यापन को बाँटता है, डेटा को कभी नहीं, इसलिए हर नोड हर बाइट ढोता है, और वक्र के शीर्ष पर एक producer अकेली बैंडविड्थ से ही डेटासेंटर-श्रेणी का है — producers के लिए एक स्वीकृत अंतिम स्थिति, और किसी और के लिए नहीं, क्योंकि सत्यापन की प्रति-नोड लागत दूसरी दिशा में जाती है (§9)। बैंडविड्थ के बाँधने से पहले, स्टेट बाँधती है: spent registry (§4) प्रति one-shot spend एक प्रविष्टि बढ़ती है, 10⁵ सर्टिफिकेट प्रति सेकंड पर प्रति वर्ष 10² टेराबाइट के क्रम में, जो §4 की घोषित खुली समस्या को एक स्थायी मद से बदलकर वह काम बना देता है जिसे वक्र अनुसूचित करता है।

स्थिरांक (genesis, दृष्टांतमूलक, जैसे §13 में): वृद्धि भाजक Γ = 512 प्रति epoch (छत पूरे ब्लॉकों के प्रति वर्ष अधिक से अधिक दुगुनी हो सकती है); क्षय भाजक Δ = 1024 (निष्क्रिय क्षमता ~2 वर्षों में आधी, genesis से कभी नीचे नहीं); burst सीमा 4T, सीमा पर producer के सब्सिडी हिस्से और ब्लॉक की fees का समर्पण (§14.1 का treasury हिस्सा अ-घटी सब्सिडी से लिया जाता है और कभी नहीं गँवाया जाता, क्योंकि burst करना producer का चुनाव है और treasury उसका पक्षकार नहीं है); स्वास्थ्य द्वार: उद्धृत प्रतिस्पर्धी headers प्रति epoch ब्लॉकों के ≤ 2%; सर्टिफिकेट (certificate)-सूची क्षमता 2²⁵ (संरचनात्मक, ऊपर के अनुसार); बाइट छत genesis पर 2.5 MB, लक्ष्य के साथ स्केल करते हुए 8 MB की संरचनात्मक बाइट क्षमता तक (eras पर फिर से टाँकी गई); प्रति-ब्लॉक हस्ताक्षर छत genesis पर 6,000, लक्ष्य के साथ स्केल करते हुए, किसी भी हस्ताक्षर के सत्यापित होने से पहले जाँची गई — सत्यापन पर एक सीमा, जो समांतर gas के मूल्य से अलग रखी गई है क्योंकि एक पैरामीटर काम को बाँध भी नहीं सकता और मार्केट का मूल्य भी नहीं लगा सकता।

9. तात्क्षणिक fraud proofs और नमूनाकरण की राह#

चूँकि validity एक सर्टिफिकेट (certificate) के बाइट्स का एक शुद्ध फलन है, इसलिए एक invalid सर्टिफिकेट स्वयं ही अपना fraud proof है। जो कोई उसे फिर से निष्पादित करे, वह उसे एक संदेश में, तुरंत, बिना किसी स्टेट और बिना किसी अन्तःक्रियात्मक द्विभाजन खेल के खंडित कर सकता है। लॉन्च विन्यास में यह बात सबसे अच्छे अर्थ में निरर्थक है: हर नोड ब्लॉक स्वीकारने से पहले हर सर्टिफिकेट सत्यापित करता है, इसलिए एक invalid सर्टिफिकेट कभी इतना नहीं टिकता कि उसे चुनौती की ज़रूरत पड़े। यह खिड़की तब सार्थक होती है जब सत्यापन नमूना-आधारित हो, और वहाँ वह एक विवाद प्रोटोकॉल के बजाय एक प्रसार पैरामीटर है: एक संदेश के नेटवर्क पार करने के लिए मुट्ठी भर ब्लॉक, जो उस underwriter के खाते में जाते हैं जिसने सर्टिफिकेट की गवाही दी (§5)। विकल्पों से तुलना कीजिए: optimistic rollups को हफ़्ते भर के अन्तःक्रियात्मक विवाद चाहिए क्योंकि विवाद के लिए विवादित क़दम पर स्टेट चाहिए; प्रमाण-आधारित सिस्टम विवाद टालते हैं पर उन provers का दाम चुकाते हैं जो निष्पादन से परिमाण के कई क्रम अधिक महँगे हैं। Zycord के fraud proofs का दाम उतना ही है जितना सत्यापन का: ~1× पुनःनिष्पादन।

यह वह स्केलिंग राह खोलता है जो पुनःनिष्पादन चेन नहीं ले सकतीं। नेटवर्क को, सिद्धांततः, यह ज़रूरी नहीं कि हर नोड हमेशा हर सर्टिफिकेट (certificate) सत्यापित करे। Underwriter bonds के होते हुए, सत्यापन नमूना-आधारित हो सकता है: प्रति सर्टिफिकेट एक VRF-चयनित समिति, इस आकार की कि किसी अ-सत्यापित invalid सर्टिफिकेट की सम्भावना नगण्य हो, जहाँ कोई भी full नोड कुछ भी जाँचने को स्वतंत्र हो और slash करने के लिए एक संदेश पर्याप्त हो। Genesis पर हर कोई सब कुछ सत्यापित करता है; यह सस्ता और समांतर है। नमूनाकरण रोडमैप है, लॉन्च नहीं। पर यही वह रोडमैप है जो उद्योग का वक्र उलट देता है: नेटवर्क बढ़ने के साथ प्रति-नोड लागत घटती है, जबकि पुनःनिष्पादन प्रतिमान की प्रति-नोड लागत थ्रूपुट के साथ तब तक बढ़ती है जब तक केवल डेटासेंटर बचें।

10. मशीन: cEVM#

Zycord एक वर्चुअल मशीन चलाता है: cEVM, जो Ethereum के EVM [2] की एक बोली है जिसे सर्टिफिकेट (certificate) के अनुकूल ढाला गया है। यह चुनाव जानबूझकर है। परियोजना का नवीनता बजट स्टेट, समवर्तिता, और आर्थिक मॉडल पर ख़र्च होता है; मशीन को सिस्टम की सबसे परिचित चीज़ होना चाहिए। Solidity, उसके कंपाइलर, ऑडिटर, और tooling साथ चले आते हैं।

मानक EVM से अंतर:

• SLOAD एक exact read में संकलित होता है (सर्टिफिकेट में घोषित); SSTORE एक SET write में।
• नए opcodes SASSERT(slot, pred) और SDELTA(slot, ±v) guarded और pure deltas उजागर करते हैं। एक SASSERT stack पर कुछ नहीं धकेलता — guards मान नहीं लौटाते (§4)।
• TIMESTAMP और NUMBER epoch beacon slot पढ़ते हैं; कोई और परिवेशी इनपुट है ही नहीं।
• Gas मापन दोहरा है (§8): स्टोरेज opcodes अनुक्रमिक gas मापते हैं; गणना, calldata, और precompiles समांतर gas मापते हैं।
• लेनदेन प्रारूप सर्टिफिकेट (certificate) है। Ethereum कॉन्ट्रैक्ट स्रोत स्तर पर port होते हैं; कच्ची wallet संगतता का दावा नहीं किया जाता, और हम इसका दिखावा भी नहीं करते। एक ported कॉन्ट्रैक्ट सर्वथा-exact मोड में चलता है: पहले ही दिन सही, और गर्म होने पर एक sequencer के ज़रिए क्रमबद्ध। समांतरता प्रति slot opt-in है, आमतौर पर एक छोटा diff (एक token का balance map ~30 पंक्तियों में SLOAD/SSTORE से SASSERT/SDELTA पर चला जाता है)। ताकि प्रमुख विशेषता ports की प्रतीक्षा करने के बजाय VM era के पहले ब्लॉक से दिखे, मशीन एक नेटिव मानक लाइब्रेरी के साथ सक्रिय होती है — token, tip jar, escrow, vesting, और एक संकर order-book/AMM संदर्भ — जो delta-पहले लिखी गई है और ज्ञात पतों पर पूर्व-तैनात है।

11. मशीन के बिना एसेट#

लॉन्च Era को कंप्यूटर की ज़रूरत से पहले एक अर्थव्यवस्था की ज़रूरत है। इसलिए Zycord ब्लॉक 0 से नेटिव एसेट को सर्टिफिकेट (certificate) संक्रियाओं के रूप में भेजता है, बिना किसी VM के: ISSUE (एक write-once cell में आपूर्ति सीमा के साथ एक asset id बनाना), MINT (guarded: minted + Δ ≤ cap), TRANSFER (guard balance ≥ Δ, युग्मित deltas; एक pure delta या एक ताज़े one-shot cell पर लक्षित credit स्वयं ही tip है, इसलिए tipping अपना कोई opcode ख़र्च नहीं करती), और RETIRE (एक पते को खर्च किए बिना जलाना: कोई reads नहीं, कोई मान नहीं हिला, एक शुद्ध write जो cell को spent चिह्नित करता है — असली spending TRANSFER के भीतर स्वतः होती है)। RETIRE अपनी जगह दो बार कमाता है। यह संहतन और गोपनीयता का प्रारम्भिक अवयव है, जो एक payee को उस क्षण एक one-shot पता मिटा देने देता है जब वह अपना काम कर चुके; और यही वह संक्रिया है जो §5 के attribution प्रमेय के एकमात्र अपवाद के पीछे है — तीसरा मामला इसलिए मौजूद है क्योंकि सेवानिवृत्ति मौजूद है, यही कारण है कि सर्टिफिकेट प्रारूप प्रति सर्टिफिकेट सेवानिवृत्त पतों की सीमा बाँधता है (§13) और यही कारण है कि प्रमेय उस किनारे को घुमाकर नहीं बल्कि उसके साथ कहा गया है। यह समुच्चय बंद है: ये चार ही सम्पूर्ण genesis निर्देश समुच्चय हैं, हर दूसरी संक्रिया — bonding सहित — किसी बाद के era के नियम-समुच्चय के साथ आती है (§14), और §5 का attribution प्रमेय ठीक इसी सतह के विरुद्ध सिद्ध किया गया है।

एक streamer जो एक ब्लॉक में दस हज़ार tips पाता है, उसका fold पर दाम दस हज़ार क्रमविनिमेय जोड़ हैं: शून्य टकराव, शून्य skips, कोई sequencer नहीं, कोई मशीन नहीं। पहले की चेन पर tipping संस्कृतियाँ प्लेटफ़ॉर्म APIs की मेहरबानी पर जीती थीं और उन्हीं के साथ मर गईं; यहाँ tip एक प्रोटोकॉल प्रारम्भिक अवयव है। और यह, संयोगवश नहीं, सिस्टम के केंद्रीय दावे का एक सतत तनाव परीक्षण भी है। नेटिव coin की आपूर्ति सीमाएँ यहीं रहती हैं, पारदर्शी पटरी पर, §3 के जाँचे गए अंकगणित से लागू, और §12 उन्हें अछूता छोड़ देता है।

12. गोपनीय भुगतान#

पिछले अनुभाग एक भुगतान की राशि को सार्वजनिक मानते हैं। यह अनुभाग उसे छिपाने का, और प्राप्तकर्ता को एक एक-बार-प्रयोग पते के पीछे छिपाने का विकल्प जोड़ता है, पिछले अनुभागों के गुणों को बनाए रखते हुए। यह डिज़ाइन उन सिस्टमों से सँकरा है जिनसे यह व्युत्पन्न है: नीचे का हर प्रतिबंध एक ऐसे हमले को बंद करता है जिसका उत्तर कोई अधिक सामान्य डिज़ाइन भारी मशीनरी से देता।

क्या छिपा है, और क्या नहीं। एक shielded भुगतान अपनी राशि छिपाता है और अपने प्राप्तकर्ता से जोड़ को टाल देता है। "टाल देता है" के बारे में सटीक रहिए: एक ताज़ा stealth output प्राप्त होने के क्षण अ-जोड़-योग्य होता है, पर बिना किसी ring के, उसे बाद में खर्च करना उस output का नाम ले लेता है जो खर्च हो रहा है, और output का नाम लेना उजागर कर देता है कि उसे किस पूर्व भुगतान ने भरा था। अ-जोड़-योग्यता पहले spend तक टिकती है और वहीं ख़त्म हो जाती है; यह एक विलम्ब है, मिटाव नहीं। और यह डिज़ाइन भेजने वाले की ग्राफ़ स्थिति भी नहीं छिपाता: सर्टिफिकेट (certificate) सार्वजनिक रूप से हस्ताक्षरित, underwritten और क्रमित होते हैं, इसलिए एक प्रेक्षक देखता है कि एक भुगतान हुआ और उसे किसने underwrite किया — राशि नहीं, और, जब तक कोई spend उसे न उजागर करे, यह भी नहीं कि प्राप्तकर्ता के outputs में से कौन कहाँ गया। ईमानदार विवरण है एक सार्वजनिक ग्राफ़ पर एक-बार-प्रयोग प्राप्तकर्ता पतों के साथ Confidential Transactions, और जैसे-जैसे outputs खर्च होते हैं, ग्राफ़ पूर्वप्रभावी रूप से बेनामी हटाता जाता है। भेजने वाले की ओर की अस्पष्टता — ring signatures, ऐतिहासिक outputs पर सदस्यता प्रमाण — कार्यक्षेत्र से बाहर है: एक ring दूसरों के outputs का सन्दर्भ लेता है, जो validity को इतिहास का फलन बना देता है, और §2 की statelessness वह गुण है जिसे प्रोटोकॉल नहीं छोड़ता। Monero के ख़तरे के मॉडल के लिए एक अलग प्रोटोकॉल चाहिए।

Shielded output. एक shielded भुगतान एक ताज़ा write-once cell (§4) लिखता है जिसका पता एक stealth address है: भेजने वाला, प्राप्तकर्ता की प्रकाशित view कुंजी और अपनी एक क्षणिक कुंजी से, एक ऐसा एक-बार-प्रयोग पता व्युत्पन्न करता है जिसे केवल प्राप्तकर्ता पहचान सकता है और जिसके लिए केवल प्राप्तकर्ता की spend कुंजी हस्ताक्षर कर सकती है। Cell का मान एक Pedersen commitment C = vG + rH है; उसके साथ एक range proof चलता है कि v ∈ [0, 2⁶⁴) और युग्म (v, r) प्राप्तकर्ता की view कुंजी को encrypt किया हुआ, साथ में एक एक-बाइट view tag जो scan करते wallet को अधिकांश पराए outputs जल्दी फेंक देने देता है। ये प्रारम्भिक अवयव stealth addressing के साथ Confidential Transactions हैं: ring के बिना RingCT का राशि-छिपाने वाला आधा, हर एक की उत्पादन में स्थापित तैनाती है।

Validity बाइट्स का फलन बनी रहती है। एक shielded सर्टिफिकेट (certificate) की balance जाँच commitment समीकरण है: घोषित इनपुट commitments घटा घोषित output commitments बराबर fee·G, जहाँ fee सार्वजनिक है (नीचे pool देखिए)। समीकरण, range proofs, और हस्ताक्षर सब केवल सर्टिफिकेट के बाइट्स से जाँचे जाते हैं, समांतर चरण में, batch होकर: Bulletproof सत्यापन एक batch के आर-पार लघुगणकीय रूप से परिशोधित होता है, और उनमें से कुछ भी स्टेट को नहीं छूता। एक गढ़ा हुआ मुद्रास्फीतिकारी सर्टिफिकेट — जिसके commitments किसी टूटी हुई मान्यता या टूटे हुए सत्यापक के अंतर्गत संतुलित नहीं होते — फिर भी विशुद्ध रूप से अपने बाइट्स से valid या invalid होता है, और fold उसे कभी दोबारा नहीं जाँचता; यह §2 का valid/applicable विभाजन है जो डिज़ाइन के अनुसार काम कर रहा है, उसका कोई अपवाद नहीं, और नीचे का pool नियम ही वह चीज़ है जो एक soundness टूट को अबद्ध होने से रोकती है। यहीं दोहरा fee मार्केट (§8) एक दक्षता तर्क होना छोड़कर एक सक्षमकारी तर्क बन जाता है: एकल-gas-मार्केट चेन पर गोपनीय लेनदेन महँगे हैं क्योंकि प्रमाण सत्यापन का एक मिलीसेकंड उसी नीलामी में एक स्टोरेज लेखन से प्रतिस्पर्धा करता है, जबकि यहाँ सत्यापन पूरी तरह par_gas में उतरता है — डिज़ाइन से सस्ता — और अनुक्रमिक मार्केट उसे कभी देखता ही नहीं।

Fold बाइट्स संग्रहीत करता है। अनुप्रयोग पर, एक shielded भुगतान वह सबसे सस्ता सर्टिफिकेट (certificate) है जो fold देखता है: उसका output cell ताज़ा है, इसलिए वह टकरा नहीं सकता (§4 का शून्य-प्रतिस्पर्धा तेज़ पथ); उसके इनपुट cells जीवित हैं या spent, यानी एक registry lookup; और write 32 बाइट का commitment संग्रहीत करता है। कोई curve अंकगणित अनुक्रमिक चरण में नहीं घुसता (§3)। यह नियम जिस विकल्प को बंद करता है वह एक persistent "संचय slot" है जिसे अजनबी homomorphically credit करें, और वह तीन मोर्चों पर विफल होता है: वह EC जोड़ को अनुक्रमिक लूप में डालता है (§3); वह एक पुनःप्रयुक्त सार्वजनिक पहचानक रचता है, यानी वही सह-स्वामित्व अनुमान जिससे बचना stealth पते का उद्देश्य है; और एक छिपा persistent balance ठीक उन तीसरे-पक्ष guards को न्योता देता है जिन्हें §4 प्रतिबंधित करता है। संचय wallet में होता है: एक प्राप्तकर्ता कई one-shot outputs रखता है, सब एक ही view कुंजी से पहचानने योग्य, और उन्हें अपने ही कई cells को एक ताज़े cell में खर्च करके समेकित करता है, यानी एक साधारण shielded सर्टिफिकेट, जिस भी लय में उसे पसंद हो, घड़ी के रूप में epoch beacon (§4) के साथ। जिस योग को एक persistent slot चेन पर बनाए रखता, उसे मालिक चेन से बाहर बनाए रखता है — और समेकन निशान से मुक्त नहीं है: एक सर्टिफिकेट में कई इनपुट घोषित करना एक सार्वजनिक सह-स्वामित्व घटना है, एक पुनःप्रयुक्त पहचानक से कमज़ोर पर असली, इसलिए wallet की नीति है उसे न्यूनतम रखना और एक ही समेकन में असम्बद्ध उद्गमों को कभी न मिलाना।

केवल-मालिक spends, और वह जो इससे वर्जित होता है। एक छिपा मान केवल उसके मालिक के अपने cell पर किए हस्ताक्षर से खर्च योग्य है। छिपे balances के विरुद्ध कोई तीसरे-पक्ष guards नहीं हैं (§4) और इसलिए shielded पटरी पर कोई pull भुगतान नहीं: कोई allowances नहीं, कोई subscriptions नहीं, कोई vault नहीं जो उपयोगकर्ता के shielded धन को समेटे। वे प्रतिरूप पारदर्शी पटरी पर बने रहते हैं, और दोनों पटरियों के बीच की सीमा एक सर्टिफिकेट (certificate) जितनी चौड़ी है। यह प्रतिबंध balance oracle को समाप्त कर देता है: जब कोई अजनबी किसी balance के विरुद्ध अनुमान जमा करके skip पढ़ ही न सके, तो oracle का कोई संचालक नहीं बचता।

Shielded pool एक सार्वजनिक पूर्णांक है जिसे fold लागू करता है। Fees सार्वजनिक हैं। Coinbase सार्वजनिक है। कॉन्ट्रैक्ट slots को भुगतान सार्वजनिक हैं। पारदर्शी और shielded पटरियों के बीच हर पारगमन एक सार्वजनिक रूप से दृश्य v हिलाता है — एक shielding सर्टिफिकेट (certificate) भीतर आते समय v खोलता है, एक unshielding सर्टिफिकेट बाहर जाते समय v खोलता है। इसलिए pool का कुल एक आरक्षित slot में रहता है, स्पष्ट पाठ में, जिसे केवल guarded delta हिलाता है (§4): shielding उसे credit करती है, pool += v; unshielding pool ≥ v पर guard लगाती है और उसे debit करती है, pool += −v; एक shielded सर्टिफिकेट की fee उसे इसी तरह debit करती है। यह slot ठीक Σ in − Σ out है, और guarded-delta अनुशासन अबद्ध पारगमनों को बिना प्रतिस्पर्धा के क्रमविनिमेय होने देता है।

यह pool को एक बाड़ बना देता है, कोई ख़तरे की घंटी नहीं। राशियाँ छिपाना §3 के जाँचे गए u256 अंकगणित को एक discrete-log मान्यता की अभिकलनीय soundness से बदल देता है, और एक टूट — मान्यता की, या कहीं अधिक सम्भाव्य रूप से किसी सत्यापक की — pool के भीतर commitments गढ़ देती है। पर एक गढ़ा हुआ commitment कोई स्पष्ट पाठ नहीं ढोता, और मान pool से केवल unshielding द्वारा निकलता है, जो सार्वजनिक slot को उसके guard के अधीन debit करती है। Slot केवल असली shielding से उठा था, इसलिए वह unshield जो उसे शून्य से नीचे ले जाए, skip हो जाती है: गढ़ा हुआ मान guard पार नहीं कर सकता। मुद्रास्फीति pool को ख़ाली नहीं करती; वह उससे बाहर निकलने में विफल रहती है। एक क्रिप्टोग्राफ़िक विफलता का विस्फोट-दायरा, किसी लेखा-परीक्षक की सजगता के बजाय एक fold नियम द्वारा, pool की असली अंतर्वस्तु तक बद्ध है, और विफलता की शैली कोई चुपचाप रिसाव नहीं बल्कि एक दृश्य, वास्तविक-समय दौड़ है जिसमें unshield करने वाले अंतिम ईमानदार धारक ऐसा नहीं कर पाते — बुरा, बद्ध, और प्रेक्षणीय, जो वही रोकथाम है जो बिना किसी आपात प्रतिक्रिया दल वाले सिस्टम के पास रचना से होनी चाहिए। नज़ीर ठोस है: Zcash Sprout जालसाज़ी बग इसलिए झेला जा सका क्योंकि उसका shielded pool एक बद्ध, लेखा-परीक्षणीय मात्रा थी; यहाँ वह मात्रा केवल लेखा-परीक्षणीय ही नहीं बल्कि fold में भार-वाहक है। §11 की नेटिव आपूर्ति सीमाएँ पारदर्शी पटरी पर रहती हैं और जाँचे गए अंकगणित से लागू बनी रहती हैं, अछूती।

Pool की एक गोपनीयता लागत है, और उसका अभिलेख में होना बनता है: सीमा-पारगमन ठीक-ठीक सार्वजनिक राशियाँ उजागर करते हैं, और विशिष्ट राशियाँ सहसम्बद्ध होती हैं। वह प्रेक्षक जो v + fee के pool में घुसने के थोड़ी देर बाद v को उससे निकलते देखता है, उसने कुछ ऐसा जान लिया जिसे किसी commitment ने नहीं छिपाया। सीमा पर मानक मूल्यवर्ग इसे भोथरा करते हैं, और wallets उन्हीं को डिफ़ॉल्ट रखते हैं; प्रोटोकॉल उन्हें अनिवार्य नहीं करता, क्योंकि एक consensus नियम एक विशिष्ट राशि को एक वैध राशि से अलग नहीं कर सकता। ट्रैफ़िक विश्लेषण के अंतर्गत जोड़-योग्यता को नकारा नहीं गया, बल्कि उसके शमन के साथ कहा गया है।

Underwriter मेटाडेटा है, और गोपनीयता तथा सेंसरशिप-प्रतिरोध एक ही सर्टिफिकेट में साथ नहीं रहते। एक स्व-बीमित shielded सर्टिफिकेट (certificate) भेजने वाले की सार्वजनिक जमा cell का नाम लेता है, जो उसे फिर से जोड़ देता है जिसे stealth पते ने अलग किया था (§5); इसलिए shielded ट्रैफ़िक co-signed underwriting पर चलता है, जहाँ एक underwriter की id कई भेजने वालों को समुच्चित करती है और भीड़ ही आवरण है। Underwriter cells की जीवंतता का मूल्य लगाता है, मानों का नहीं (§5), इसलिए वह राशि नहीं जानता — पर वह बाक़ी सब जान जाता है जो सर्टिफिकेट है: वह भेजने वाला जिससे उसे बाहर-बाहर वसूलना है और इसलिए पहचानना है, वे cells जो खर्च हो रहे हैं, वे stealth outputs जो बन रहे हैं, और समय। यही ठीक वह है जो एक समन चाहता है, और ऊपर वाले पूर्वप्रभावी बेनामी-हरण के साथ यह सार्वजनिक ग्राफ़ के ज़रिए आगे की ओर संयोजित होता है। यह एक संरचनात्मक KYC बिंदु भी है, क्योंकि एकमात्र निजी मोड का एक जाना-जा सकने वाला संचालक है। इससे एक सीमा उजागर होती है जिसे पेपर ढँकने के बजाय साफ़-साफ़ कहता है: दो underwriting मोड हैं, co-signed (निजी, पर अनुमति-आधारित — एक underwriter आपको मना कर सकता है) और स्व-बीमित या forced (अनुमति-रहित, पर स्वयं-पहचान कराता)। §7 का forced पथ गारंटी देता है कि एक सेंसर किया गया उपयोगकर्ता हमेशा लेनदेन कर सकता है; वह यह गारंटी नहीं देता कि वह निजी रूप से लेनदेन कर सकता है। वह उपयोगकर्ता जिसे हर underwriter मना कर दे, खर्च करने का अधिकार रखता है और उसी गति में गोपनीयता खो देता है — और ठीक वही उपयोगकर्ता है जिसके लिए गोपनीयता मायने रखती थी। Shielded पटरी को §7 का सेंसरशिप-प्रतिरोध केवल अपनी ही गोपनीयता की क़ीमत पर मिलता है; ये दोनों गुण एक अकेले सर्टिफिकेट में नहीं टिकते।

एक era, genesis नहीं। दो स्वतंत्र तर्क अनुसूची तय करते हैं। व्यवहार में, shielded सर्टिफिकेट (certificate) co-signed underwriters का उपयोग करते हैं, जो Era 1 से मौजूद हैं। §3 के सिद्धांत से, अगम्य consensus कोड अ-लेखा-परीक्षणीय consensus कोड है और उसे भेजा नहीं जाता: genesis binary में कोई commitments नहीं, कोई range-proof सत्यापक नहीं, कोई pool slot नहीं — कुछ भी ऐसा नहीं जिसका एकमात्र caller कोई भावी era हो। Shielded era विशुद्ध रूप से योगात्मक नहीं है, और पेपर यह कह देता है: §4 का छिपा-cell टाइपिंग और तीसरे-पक्ष-guard प्रतिबंध fold के guard पथ को छूते हैं, जो genesis-महत्वपूर्ण सतह है, इसलिए यह era जोड़ता भी है और बदलता भी है, और उसका सक्रियण एक hard fork है जिसका उसी consensus-महत्वपूर्ण बदलाव के रूप में लेखा-परीक्षण होता है जो वह है। वह era जो अपनी जटिलता के लायक़ साबित न हो, बस कभी सक्रिय नहीं किया जाता, और उसे न समेटकर genesis चेन ने कुछ नहीं खोया।

लागतें, साफ़-साफ़ कही गईं। एक shielded सर्टिफिकेट (certificate) एक पारदर्शी से 3–5× आकार का होता है — एक से दो किलोबाइट, जिस पर batch समुच्चयन के बाद भी range proof हावी रहता है — जिसे गतिशील ब्लॉक (§8) आर्थिक रूप से सोख लेता है और §13 का वितरण बैंडविड्थ में चुकाता है। प्राप्तकर्ता भुगतानों को scan करके खोजते हैं: हर नए shielded output को wallet की view कुंजी के विरुद्ध परखा जाता है, जो नेटवर्क-आयतन में एक O(n) लागत है, जिसे view tags एक बाइट पर जल्दी अस्वीकार करके घटाते हैं, एक अचर गुणक जो उससे पहले होने वाली साझा-गुप्त व्युत्पत्ति से बद्ध है। Scanning shielded पटरी का प्रमुख UX भार है; बाहर से करवाया गया scanning जो view कुंजी न सौंपे, एक खुली समस्या है जिसे यह डिज़ाइन सुलझाने के बजाय विरासत में पाता है। इस पटरी पर relay नीति भी बदलनी होगी, और वैकल्पिक रूप से नहीं: एक सर्टिफिकेट प्रकाशित करना मुफ़्त है (§5, §13) जबकि एक Bulletproof सत्यापित करना नहीं, इसलिए वह relay जो प्रकाशक पर कोई लागत थोपे जाने से पहले सत्यापक चला दे, एक denial-of-service प्रवर्धक है — shielded पटरी के लिए सस्ता-पहले-महँगा-बाद-में जाँचने वाला relay चाहिए (हस्ताक्षर और घोषित जीवंतता पहले, प्रमाण अंत में, प्रति-underwriter कोटा), जो mempool के "relay नीति से बद्ध" को एक डिफ़ॉल्ट से एक आवश्यकता बना देता है।

वे खुले प्रश्न जो यह अनुभाग किसी बाद के प्रारूप पर छोड़ता है, दफ़्न करने के बजाय चिह्नित किए गए। क्या shielded पटरी केवल नेटिव coin ढोती है या §11 के एसेट भी: एक अकेला जनक H vG + rH को एक अदिश के प्रति प्रतिबद्ध करता है, न कि एक (asset, value) युग्म के प्रति, इसलिए एक बहु-एसेट shielded पटरी को प्रति-एसेट जनक चाहिए (Confidential Assets), जो प्रमाण का आकार और ऊपर का "3–5×" आँकड़ा बदल देता है; जब तक तय न हो, पटरी नियम से केवल-नेटिव-coin है, चूक से नहीं। क्या RETIRE (§11) shielded cells पर काम करता है: यदि करता है, तो मान बिना किसी सार्वजनिक unshield के pool से निकल सकता है, इसलिए pool slot एक ऊपरी सीमा बन जाता है (Σ in − Σ out ≥ अंतर्वस्तु) और मुद्रास्फीति-पहचान की दिशा को एक असमिका के रूप में फिर से कहना होगा; यदि नहीं करता, तो shielded पटरी अपना कचरा-संग्राहक खो देती है और न-खुल सकने वाले outputs (नीचे) जमा होते जाते हैं। क्या encrypted (v, r) सर्टिफिकेट (certificate) के शरीर में रहता है (अभी सस्ता, पर शरीर prune होने पर अपुनर्प्राप्य, जो केवल-seed वाली wallet बहाली को विफल कर देता है) या cell मान में (प्रति output स्टेट का दाम, cell के खर्च होने पर ग़ायब, और "संचय wallet में होता है" के साथ संगत)। और क्या एक underwriter किसी तीसरे पक्ष को bond कर सकता है जबकि सर्टिफिकेट के भीतर सार्वजनिक मान में शुल्क वसूले, जो ऊपर की पहचान आवश्यकता को हटा देगा और गोपनीयता/सेंसरशिप सीमा से आगे निकलने का सबसे आशाजनक रास्ता है — ये डिज़ाइन के मामले हैं, शब्दों के नहीं, और यहाँ इसलिए नाम दिए गए हैं ताकि अगला प्रारूप उन्हें चुपचाप विरासत में न पा ले।

13. नेटवर्क#

शरीर चेन डेटा हैं। ब्लॉक के valid होने के लिए उसके सर्टिफिकेट (certificate) शरीर पुनःप्राप्त किए जा सकने चाहिए; इसलिए स्टेट हमेशा केवल चेन से पुनर्निर्मित की जा सकती है, और कोई संचालक — sequencer सहित — कभी डेटा का संरक्षक नहीं होता। सर्टिफिकेट शास्त्रीय लेनदेनों से बड़े होते हैं (वे reads और writes ढोते हैं), और उपशमन संरचनात्मक हैं: batch सर्टिफिकेट आंतरिक writes काट देते हैं (§6), और spent one-shot cells reorg horizon से आगे दफ़्न हो जाने पर संहत हो जाते हैं (§4)।

एक तीसरा उपशमन सम्भावित है और उसे मान लेने के बजाय वैसा ही नाम दिया गया है: एक read मान दोहराने के बजाय किसी पूर्ववर्ती सर्टिफिकेट (certificate) के write का सन्दर्भ (cert_id, index) से ले सकता था — यानी UTXO वाली चाल। वह यहाँ वर्णित प्रोटोकॉल का हिस्सा नहीं है, और तब तक नहीं बनेगा जब तक एक प्रश्न का उत्तर न मिले, क्योंकि यह प्रश्न encoding का नहीं बल्कि consensus का है: जब वह सर्टिफिकेट जिसका सन्दर्भ लिया गया, skip हो गया हो या कभी शामिल ही न हुआ हो, तब वह सन्दर्भ किस पर हल होता है। वह सन्दर्भ जो चुपचाप वर्तमान मान पर हल हो जाए, अब कोई घोषित read नहीं रहा, और उसके साथ stateless validity मर जाती है; और वह जो विफल हो जाए, उन सर्टिफिकेटों को गिरा देता है जिनके अपने अधिकृतीकरण पर कभी संदेह ही नहीं था। वह संपीड़न जिसका दाम वही गुण हो जिस पर पूरा डिज़ाइन टिका है, रखने लायक़ संपीड़न नहीं है, इसलिए यह फ़ील्ड तब तक अनुपस्थित है जब तक अर्थ तय न हो जाए।

Relay हैश-पहले है। सर्टिफिकेट (certificate) स्वतंत्र रूप से gossip होते हैं और आगमन पर validity-जाँचे जाते हैं (stateless रूप से, समांतर में); ब्लॉक mempool के विरुद्ध headers और हैश सूचियों के रूप में relay होते हैं, compact-block शैली में [13], इसलिए प्रसार विलम्ब ब्लॉक की अंतर्वस्तु के साथ स्केल नहीं करता। एक relay नोड को spam को पूरी तरह छानने के लिए किसी भी स्टेट की ज़रूरत नहीं — stateless validity और underwriter हस्ताक्षर बाइट्स से जाँचे जा सकते हैं, जो पारदर्शी पटरी पर relay अवसंरचना चलाना लगभग मुफ़्त बना देता है। Shielded पटरी (§12) मूल्यांकित अपवाद है: उसकी stateless जाँच में एक range-proof सत्यापन शामिल है जिसका दाम एक हस्ताक्षर से परिमाण के तीन क्रम अधिक है, इसलिए वहाँ मुफ़्त-में-प्रकाशित वाला डिफ़ॉल्ट एक प्रवर्धक बन जाता है, और relay सस्ता-पहले-महँगा-बाद-में वाले अनुशासन और प्रति-underwriter कोटों से बद्ध है जिन्हें §12 वरीयता के बजाय आवश्यकता बनाता है। एक पटरी का relay लगभग मुफ़्त है; दूसरी का सस्ता केवल इसलिए है क्योंकि उसकी नीति अनिवार्य है।

पैरामीटर (genesis, दृष्टांतमूलक)। 30-सेकंड ब्लॉक; सर्टिफिकेट (certificate) TTL डिफ़ॉल्ट 240 ब्लॉक (~2 घं.); प्रति सर्टिफिकेट सेवानिवृत्त पते ≤ 64; epoch 2,880 ब्लॉक (~1 दिन); forced-अनुप्रयोग विलम्ब D = 4 ब्लॉक; forced-समावेशन सीमा F = 16 ब्लॉक; era-ट्रिगर stake खिड़की K = 14 epochs (~2 सप्ताह); treasury हिस्सा ब्लॉक सब्सिडी का 300 आधार अंक (3%) ब्लॉक 0 से, cell Era 2 तक सील, फिर एक hard fork से टाँके गए कुंजी समुच्चय पर 3-में-से-5, कुंजी-आवर्तन विलम्ब R = 20,160 ब्लॉक (~7 दिन) (§14.1); निर्गमन स्थिरांक §14.2 में।

14. लॉन्च: तीन Eras, शून्य premine#

Zycord बिना किसी premine, बिना किसी संस्थापक आवंटन, बिना किसी निवेशक दौर, और बिना किसी admin कुंजी के लॉन्च होता है। Genesis प्रकाशित स्रोतों से पुनरुत्पाद्य है। पहले एक testnet चलता है; उसके स्थिर होने पर ही एक mainnet तिथि की घोषणा होती है, खुले में और पहले से, ताकि ब्लॉक 0 उस हर व्यक्ति की पहुँच में हो जो उसे चाहता है। लेखक पर जो लागू किया जाता है वह विशेषाधिकार की अनुपस्थिति है, और वह genesis में पंक्ति दर पंक्ति जाँची जा सकती है। उन्नयन सामाजिक consensus और hard fork से होते हैं।

यह पेपर तर्क है। नियम आर्किटेक्चर विनिर्देश हैं, golden vectors प्रोटोकॉल हैं, और जहाँ उनमें से कोई दो असहमत हों वहाँ अधिक सटीक वाला जीतता है और असहमति एक बग है। उनके साथ इस डिज़ाइन पर हुए हमलों का अभिलेख भी प्रकाशित है — क्रमिक विरोधी पठन, उनसे निकले निष्कर्ष, वे जिन्होंने नियम बदले, और वे जिन्हें तर्क से ख़ारिज किया गया और क्यों। वह अभिलेख पूरा और अ-सम्पादित जारी किया जाता है, उन समीक्षाओं सहित जिन्होंने असली दोष पकड़े और उन उपकरणों सहित जिन्होंने कुछ भी न मापते हुए सफलता की सूचना दी। जिस परियोजना का लेखक ख़ुद सामने आकर उसकी ज़मानत नहीं देगा, उसके लिए वह डिज़ाइन जिस पर हमले का कोई दृश्य इतिहास न हो, ऐसा पढ़ा जाता है मानो उस पर किसी ने हमला ही न किया हो, और उसे छिपाने का जो दाम पड़ता, उसे वापस कमाने का कोई तरीक़ा नहीं है।

"अ-सम्पादित" निष्कर्षों के बारे में एक वादा है, और यह ठीक-ठीक कहना उचित है कि वह किसे ढँकता है, क्योंकि अभिलेख एक जीवंत संग्रह के बजाय फ़ाइलों के रूप में पुनःप्रकाशित होता है। हर निष्कर्ष, हर मापन, हर तर्क और हर अस्वीकृत विकल्प वैसा ही बचा रहता है जैसा लिखा गया था, उन सहित जो ग़लत थे और उन उपकरणों सहित जिन्होंने कुछ भी न मापते हुए सफलता की सूचना दी; कुछ भी पतला, नरम, विलीन या हटाया नहीं जाता। दो वर्गों के बदलाव किए जाते हैं और केवल दो। पहला पहचान का विलोपन है — नाम, handles, पते, मशीन नाम और स्थानीय पथ, जो डिज़ाइन के बारे में कुछ नहीं कहते। दूसरा स्वयंपूर्णता है: किसी tracker या commit इतिहास में जाता सूचक, जिसे प्रकाशित वृक्ष नहीं ढोता, उस तर्क से बदल दिया जाता है जिसके लिए वह खड़ा था, वहीं पंक्ति में कहा हुआ। इसलिए केवल ये फ़ाइलें रखने वाला पाठक हर दावे का अनुसरण कर सकता है, और यह वादा इसीलिए था; वह सूचक जो कहीं हल ही न हो, "अ-सम्पादित" का अक्षर बचाए रखता और उसका पूरा प्रयोजन खो देता।

Proof of stake fair-launch नहीं कर सकता — प्रारम्भिक stake कहीं न कहीं से आना ही है, और हर शास्त्रीय रास्ता (बिक्री, premine, आवंटन) या तो नेटवर्क को केंद्रित करता है या उसके लेखक की पहचान कराता है। इसलिए proof of work का उपयोग एक समाप्ति तिथि वाले वितरण तंत्र के रूप में किया जाता है, स्थायी consensus के रूप में नहीं:

संक्रमण पर डिज़ाइन नोट्स। Era 0 जानबूझकर नन्हा है। बिना admin कुंजियों के कोई pause बटन नहीं है, इसलिए genesis की हर पंक्ति ऐसी पंक्ति है जो नेटवर्क को बिना उपचार के मार सकती है; fold (§3) और नेटिव संक्रियाएँ (§11) मिलकर पूरी safety-महत्वपूर्ण सतह हैं (इतनी छोटी कि यह पेपर उनका पूरा विनिर्देश समेट लेता है), और वे लेखा-परीक्षित और विरोधी रूप से अनुरूपित होकर भेजी जाती हैं। CPU माइनिंग (RandomX) जनसांख्यिकी से मेल खाती है: उसी लैपटॉप पर mine कीजिए जो आपके पास पहले से है। यह botnets को न्योता भी देती है; हर CPU-mine-योग्य coin ने उनसे लड़ाई लड़ी है, और हमें अपवाद होने की उम्मीद नहीं। हम यह सौदा खुली आँखों से करते हैं: botnets से तिरछा हुआ वितरण भी उससे व्यापक है जो किसी बिक्री में तय हो, और ईमानदार सामान्य हार्डवेयर को प्रतिस्पर्धी बनाए रखना RandomX का पूरा डिज़ाइन उद्देश्य है [14]। Co-signing उसी क्षण से जीवंत है जब से underwriters पंजीकरण कर सकें; checkpoint finality तब तक नहीं, जब तक stake न टिके, और हम इस अंतराल को छिपाने के बजाय नाम देते हैं: bond skips का मूल्य लगाता है, reorgs का कभी नहीं, इसलिए कोई प्रोटोकॉल नियम किसी underwriter को उस अंतराल में पूर्व-पुष्टियाँ बेचने से नहीं रोकता — जो कोई नियम नहीं कर सकता वह है उस बिक्री को ईमानदार बनाना। "सेकंडों में लागू होगा वरना मेरा bond चुकाएगा" तभी underwrite करने योग्य है जब गहरे reorgs मेज़ से हट जाएँ, इसलिए बीमित-पूर्व-पुष्टि उत्पाद finality का अनुसरण प्रोटोकॉल क़ानून के रूप में नहीं बल्कि बाज़ार की ईमानदारी के रूप में करता है। गवाहों को overlay सक्रिय होने के क्षण से निर्गमन से भुगतान मिलता है — पहले के दोनों संकर संक्रमणों ने यही किया (Decred हर ब्लॉक इनाम का एक हिस्सा PoS मतदाताओं को देता है [17]; Ethereum के beacon validators ने mainnet ब्लॉक प्रस्तावित करने से दो साल पहले निर्गमन कमाया) — और producer-भारी 77/20/3 विभाजन वितरण चरण तक सीमित है, क्योंकि वही नज़ीर दिखाती है कि miner-भारी विभाजन ग़लत स्थायी स्थिति है: ramp उसे सेवानिवृत्त कर देता है। Era 1 अपना ट्रिगर बाँट देता है, और यह विभाजन भार-वाहक है: निर्देश समुच्चय ऊँचाई से सक्रिय होता है — पहले BOND, फिर underwriter और sequencer पंजीकरण और cEVM, दो ऊँचाइयाँ जिन्हें genesis पैरामीटर अलग और क्रमित रखते हैं — जबकि finality overlay केवल तब सक्रिय होता है जब bonded stake ≥ आपूर्ति का 1% K epochs तक टिक चुका हो, क्योंकि stake को उस संक्रिया के अस्तित्व में आने से पहले नहीं मापा जा सकता जो उसे रचती है। Era 2 एक दोहरा ट्रिगर रखता है (ऊँचाई और टिका हुआ stake), ताकि नेटवर्क न तो तुच्छ stake पर संक्रमण करे और न ही पदस्थ miners को उसे हमेशा के लिए रोक देने दे; ऊँचाइयाँ सीमाएँ हैं, तिथियाँ नहीं, और किसी कैलेंडर का वादा नहीं है। एक चेतावनी जिसे हम दफ़्न करने के बजाय कहते हैं: 1% वाले सक्रियण तल पर, finality रोक देने के लिए उसका एक-तिहाई (आपूर्ति का 0.33%) चाहिए, इसलिए वह finality जिस पर पहली बीमित पूर्व-पुष्टियाँ टिकती हैं, स्वयं युवा है। K-epoch तक टिकने की आवश्यकता समय के साथ बाधा ऊँची करती है, निष्क्रियता रिसाव किसी रुकावट को थामे रखना महँगा बना देता है, और underwriters से अपेक्षा है कि वे युवा finality का मूल्य युवा पॉलिसियों में लगाएँ; गहरी सुरक्षा गहरे stake के साथ आती है, घोषणा से नहीं। Era 1 छाया चेन है: validator समुच्चय एक भी ब्लॉक प्रस्तावित करने से पहले पूरे era तक उत्पादन में finality करता है — असली bonds, असली slashing — वही गुण जिसने बड़े पैमाने पर हुए एकमात्र सफल PoW→PoS संक्रमण को सुरक्षित बनाया। यह एक विश्राम स्थिति भी है, कोई गलियारा नहीं: यदि stake कभी Era-2 सीमा तक न टिके, तो नेटवर्क अनिश्चित काल तक एक काम करता संकर बना रहता है। इनाम का ramp, किसी कगार के बजाय, एक miner-fork उभार को उसका क्षण नहीं देता, और ramp रोका जा सकता है: यदि लगातार दो epochs तक checkpoints अंतिम होने में विफल रहें, तो वह अपने वर्तमान स्तर पर तब तक रुक जाता है जब तक finality लौट न आए। Miners यह रुकावट ख़रीद नहीं सकते: finality रोकने के लिए bonded stake का एक-तिहाई चाहिए, जिसे निष्क्रियता रिसाव finality लौटने तक बहाता रहता है, इसलिए इस हमले का दाम रुके हुए इनाम से अधिक है। वे Era-0 miners जो अपना coinbase bond करते हैं, उन्हें पहली sequencer आवर्तनों में प्राथमिकता मिलती है — अतिरिक्त coins नहीं — जो माइनिंग समुदाय को फेंकने के बजाय संचालक समुदाय में बदल देती है।

Shielded era का ट्रिगर जानबूझकर बाक़ियों से अलग आकार का है। ऊँचाइयाँ और stake सीमाएँ ऐसे तथ्य हैं जिन्हें एक नोड मापता है; एक क्रिप्टोग्राफ़िक सत्यापक की तैयारी वैसी नहीं है, इसलिए ट्रिगर इसके बजाय एक चेकलिस्ट है जिसे एक hard fork उद्धृत कर सकने में सक्षम होना चाहिए: लेखा-परीक्षाएँ प्रकाशित, testnet epochs पूरे किए गए, vectors कलाकृति में। रूप मदों से अधिक मायने रखता है। इस नेटवर्क के पास कोई आपात प्रतिक्रिया दल नहीं है — Zcash जालसाज़ी बग आंशिक रूप से इसलिए झेला जा सका क्योंकि एक कर्मचारी-युक्त संगठन ने दिनों में सुधार भेज दिया, और यहाँ कुछ भी उसका वादा नहीं कर सकता — इसलिए era का सक्रियण अपने अनुरक्षकों को मान लेने के बजाय उन्हें रचने के लिए डिज़ाइन किया गया है: वह समुदाय जो दो स्वतंत्र लेखा-परीक्षाएँ नहीं करा सकता और एक विरोधी testnet नहीं चला सकता, वह समुदाय एक consensus सत्यापक का अनुरक्षण नहीं कर सकता, और चेकलिस्ट दूसरी अक्षमता को पहली की विफलता के रूप में दृश्य बना देती है, किसी टूट के बाद नहीं बल्कि सक्रियण से पहले। §12 का fold नियम बाँधता है कि एक बचा रह गया बग कितना पड़ सकता है; चेकलिस्ट बाँधती है कि उस क्षण एक सत्यापक कितना अ-परखा हो सकता है जब वह कुछ भी पड़ना शुरू करे। कोई भी दूसरे की जगह नहीं लेता, और era दोनों के साथ भेजा जाता है या बिलकुल नहीं।

Ramp एक पुनर्विभाजन है, कोई कटौती नहीं: proof of work जो भी हिस्सा छोड़ता है, वह proof-of-stake proposers ले लेते हैं, इसलिए §14.2 की सब्सिडी अनुसूची इससे अछूती रहती है कि नेटवर्क अपने संक्रमण में कहाँ है। यही अनुसूची को ऊँचाई का एक शुद्ध फलन बने रहने देता है, जिसे कोई भी नोड चार स्थिरांकों से, लेजर देखे बिना, गणना कर सकता है।

यह संक्रमण एक ऐसे स्थापत्य कारण से साध्य है जिसे कहना उचित है: fold इस बारे में अज्ञेय है कि क्रम कौन लगाता है। एक PoW miner पहले से ही वह अंधा proposer है जिसकी डिज़ाइन को ज़रूरत है; Era 2 यह बदलता है कि header पर किसका हस्ताक्षर है, और स्टेट अर्थशास्त्र का एक भी नियम नहीं। सीमा के आर-पार ढोने को कोई निष्पादन इंजन है ही नहीं।

एक era सीमा वही जगह भी है जहाँ क्षमता हिलती है: §8.1 की बाइट क्षमता और उसके नीचे के परिवहन स्थिरांक वहीं फिर से टाँके जाते हैं, चलते नेटवर्क पर मापे गए प्रसार के विरुद्ध, ताकि नियमित वृद्धि अपने आप में एक शासन घटना बनने के बजाय उन उन्नयनों पर सवार हो जो यह अनुसूची पहले से समेटे है।

14.1 Treasury#

हर ब्लॉक सब्सिडी का तीन प्रतिशत treasury cell में credit होता है; सत्तानवे प्रतिशत consensus को चुकाता है — ब्लॉक के producer को और, Era 1 से, checkpoint गवाहों को (§14)। यह हिस्सा genesis में तय है, ब्लॉक 0 से लागू होता है, और हर ब्लॉक पर एक समान लागू होता है। Fees कभी नहीं छुई जातीं (treasury का §8 के मार्केटों पर कोई दावा नहीं), इसलिए लागत निर्गमन पर पड़ती है, जो हर धारक पर उसकी धारिता के अनुपात में फैलती है।

Cell Era 2 तक सील है। वह ब्लॉक 0 से संचित होता है और उससे पहले उसे कोई कुंजी नहीं खोलती: genesis में कोई कोरम नहीं, कोई पता नहीं, कोई लेखक कुंजी नहीं, कोई आपात पथ नहीं। ब्लॉक 0 पर कुंजियाँ रखने के लिए कोई परिपक्व समुदाय है ही नहीं। यदि कोई न आए, तो cell कभी नहीं खुलता और coins कभी जारी नहीं होते। संचय नियम पहले ब्लॉक से genesis में बैठा है ताकि वह कभी एक बदलाव न हो; Era 2 पर नया कुछ नहीं होता, सिवाय इसके कि एक सहमत नियम प्रभावी हो जाता है।

इसमें से कुछ भी premine नहीं है, और यह अंतर आलंकारिक के बजाय जाँचने योग्य है। Premine एक आवंटन है: coins, एक पता, और एक कुंजी जो genesis पर मौजूद हों और किसी की हों। यहाँ genesis में तीनों में से कोई नहीं है। कोई treasury coin खर्च योग्य नहीं, कोई पता नियत नहीं, कोई कुंजी मौजूद नहीं, और किसी पक्ष का नाम नहीं; genesis में जो है वह एक नियम है, जो अब तक mine हुए हर ब्लॉक पर एक समान लागू होता है, और साथ में एक दूसरा नियम कि संचित परिणाम पर एक दिन एक कोरम कैसे टाँका जा सकता है। वह दिन आता है या नहीं, यह लेखक के हाथ में नहीं है। चूँकि कुंजी समुच्चय एक hard fork से टाँका जाता है, इसलिए चयन तंत्र वही है जो हर consensus बदलाव उपयोग करता है: कोई पाँच सार्वजनिक रूप से पहचाने गए धारकों का प्रस्ताव करता है, नोड संचालक उन्हें टाँकने वाला fork अपनाते हैं या उसे चलाने से मना कर देते हैं, और वह उम्मीदवार कोरम जो नेटवर्क को अपना fork चलाने के लिए मना न सके, किसी चीज़ की कुंजियाँ नहीं रखता। पकड़ने को कोई मतदान नहीं है, खेलने को योगदानकर्ताओं की कोई पंजी नहीं है, और ऐसा कोई क्षण नहीं जिसमें लेखक की आवाज़ किसी भी अन्य नोड संचालक की आवाज़ से भारी हो।

Era 2 से cell केवल उस सर्टिफिकेट (certificate) से debit होता है जो एक hard fork से टाँके गए कुंजी समुच्चय पर पाँच में से तीन हस्ताक्षर ढोता हो। Spends साधारण सर्टिफिकेट हैं: सार्वजनिक, अंतिम, और केवल चेन से गिने जा सकने योग्य। कोरम उन योगदानकर्ताओं में से लिया जाता है जो खुलने के समय सक्रिय हों और समुच्चय के प्रभावी होने से पहले सार्वजनिक रूप से पहचाने गए हों; हर कुंजी एक अलग पक्ष के पास बैठती है, कोई भी साझा नियंत्रण में नहीं। एक valid 3-में-से-5 spend इसके बजाय पाँच प्रतिस्थापन कुंजियों का नाम ले सकती है, जो R ब्लॉक बाद प्रभावी होती हैं, जिस दौरान आवर्तन सार्वजनिक रहता है और पुराना समुच्चय अब भी क़ायम रहता है: आवर्तन एक spend की सीमा और एक spend की दृश्यता ढोता है।

Eras 0 और 1 दान-वित्तपोषित हैं: प्रस्ताव भुगतान से पहले सार्वजनिक, मील के पत्थर और बजट पहले से, वितरित कार्य के विरुद्ध विमोचन, अख़र्च रकम कोष में वापस। Cell के खुलने पर कोरम को वही अनुशासन विरासत में मिलता है। यह एक प्रथा है, कोई consensus नियम नहीं; उसे जो लागू करता है वह यह है कि हर विचलन लेजर में दिखता है।

यह हिस्सा समाप्त नहीं होता। यह coins की मात्रा के बजाय निर्गमन का एक अंश है, इसलिए यह §14.2 की सब्सिडी के साथ क्षय होता है और पूँछ पर एक निश्चित नाममात्र धारा के रूप में बना रहता है; आपूर्ति के अंश के रूप में यह शून्य की ओर जाता है। इसे हटाने का दाम वही है जो किसी भी consensus बदलाव का: एक hard fork। Era 2 से यह 3-में-से-5 प्रोटोकॉल का एकमात्र विश्वस्त कोरम है।

14.2 निर्गमन#

सब्सिडी सुचारु रूप से क्षय होकर एक चिरस्थायी पूँछ तक जाती है। दर एक epoch के भीतर अचर रहती है और हर epoch सीमा पर एक बार नीचे उतरती है, चार स्थिरांकों पर सटीक पूर्णांक अंकगणित से:

E(0) = E₀
E(n) = max(tail, E(n−1) − E(n−1)/Q)

जहाँ L ब्लॉकों में epoch है, Q क्षय भाजक, E₀ genesis सब्सिडी, और E(n) पूरे epoch n में प्रति-ब्लॉक सब्सिडी। वे चार — L, Q, E₀, tail — ही स्थिरांक हैं; C, यानी वह पूर्व-पूँछ आपूर्ति जिस तक अनुसूची का योग जाता है, पुनरावृत्ति चलाकर उनसे व्युत्पन्न होती है और उसका इनपुट नहीं है। पहले के संशोधन पहली पंक्ति को E(0) = C / (L · Q) लिखते थे, जो ऐसा पढ़ा जाता है मानो C कोई स्थिरांक हो जिसमें से सब्सिडी भाग की जाती हो; वह अनन्त ज्यामितीय क्षय का बंद रूप है, और नीचे की परिमित अनुसूची का योग उस तक नहीं जाता। कोई floats नहीं और ग़लत हो सकने वाली कोई तालिका नहीं, और कोई halving कगार नहीं: क़दम इतना छोटा है कि कोई एक ब्लॉक उसे देखता ही नहीं, वही तर्क जो Era-2 इनाम को एक ramp बनाता है। एक बार सूत्र पूँछ से नीचे गिर जाए, तो सब्सिडी हमेशा के लिए प्रति ब्लॉक एक निश्चित राशि रह जाती है।

यह अनुसूची ऊँचाई का एक शुद्ध फलन है। वह यह नहीं देखती कि वास्तव में कितना चुकाया गया, जिसका अर्थ है कि वह ब्लॉक जो अनुसूची से कम चुकाता है — मान लीजिए एक coinbase जो ऐसे पते का बकाया हो जिसके धारक ने उसे जला दिया — वह C के विरुद्ध एक स्थायी कमी है, न कि कोई ऋण जिसे वक्र बाद में चुका दे। इसलिए C वह आँकड़ा है जिस तक अनुसूची का योग जाता है, कोई ऐसी सीमा नहीं जिस तक पहुँचने की वह गारंटी देती हो।

पूँछ इसलिए मौजूद है क्योंकि सुरक्षा एक स्थायी ख़र्च है: वह उसे चुकाती है जो वर्तमान era को सुरक्षित करता है — miners, फिर miners और गवाह, फिर validators — बिना §8 के fee मार्केटों को भर्ती किए। उसका आकार ऐसा है कि वार्षिक पूँछ निर्गमन बक़ाया आपूर्ति के 1% से नीचे शुरू होता है; चूँकि अंश निश्चित है और आपूर्ति बढ़ती है, इसलिए वह प्रतिशत केवल गिरता है। उसके विरुद्ध §8 का अनुक्रमिक base-fee burn चलता है, इसलिए शुद्ध निर्गमन पूँछ घटा burn है और भार के अंतर्गत ऋणात्मक हो सकता है। §14.1 का 97/3 विभाजन हर सब्सिडी पर लागू होता है, पूँछ सहित।

स्थिरांक (genesis, दृष्टांतमूलक, जैसे §13 में): epoch L = 2,880 ब्लॉक; क्षय भाजक Q = 1054; genesis सब्सिडी E₀ = 21/ब्लॉक; पूँछ 0.33/ब्लॉक। 30-सेकंड ब्लॉकों के साथ ये 0.70702 का वार्षिक गुणक देते हैं, यानी उत्सर्जन दर हर दो साल में आधी हो जाती है — और ठीक-ठीक, लगभग नहीं: E₀ = 21 के मुक़ाबले E(730) = 10.50230028। सूत्र epoch 4,376 पर, ऊँचाई 12,602,880 पर, ≈ वर्ष 12 में पूँछ से नीचे गिरता है, इसलिए क्षय होती भुजा epochs 0 से 4,375 तक चलती है और C, यानी वह आपूर्ति जिस तक उसका योग जाता है, 62,744,838.47 है। उसमें से 62,744,817.47 वास्तव में जारी होती है: अंतर genesis ब्लॉक के 21 का है, जो कोई coinbase चुकाता ही नहीं क्योंकि चुकाने को कोई miner नहीं है और एक पुनरुत्पाद्य genesis को किसी पते को credit नहीं करना चाहिए। तब वार्षिक पूँछ निर्गमन ≈347K है, यानी जारी आपूर्ति का 0.55%, और वहाँ से गिरता जाता है। **बंद रूप L · E₀ · Q = 63,745,920 C पर एक ऊपरी सीमा है, उसका मान नहीं**, और यह अंतर कोई सन्निकटन त्रुटि नहीं है: वह गुणनफल अनन्त ज्यामितीय क्षय का योग है, जबकि अनुसूची परिमित है, हर क़दम पर तल लेती है और पूँछ पर रुक जाती है। वह C से 1,001,081.53, यानी 1.60%, आगे निकल जाता है। योग उद्धृत कीजिए, बंद रूप कभी नहीं। अनुरूपता का अर्थ है पुनरावृत्ति को पुनरुत्पादित करना — कोई नोड किसी भी ऊँचाई पर कभी C, या इस अनुच्छेद का कोई और आँकड़ा, गणना नहीं करता।

15. मापन#

वह डिज़ाइन जिसका केंद्रीय दावा एक थ्रूपुट असमिति है, पाठक को आँकड़े देने का ऋणी है। नीचे के आँकड़े संदर्भ कार्यान्वयन से हैं और उसके प्रकाशित स्रोत से फिर से व्युत्पन्न किए जा सकते हैं। हार्डवेयर: एक दस-कोर x86 डेस्कटॉप CPU। आँकड़े 5 runs पर median हैं।

• Fold थ्रूपुट: 100,000 slots के कार्यकारी सेट पर प्रति कोर प्रति सेकंड 883,000 slot संक्रियाएँ, यानी प्रति सर्टिफिकेट (certificate) 3 slots पर प्रति सेकंड 294,000 लागू सर्टिफिकेट।
• Stateless सत्यापन: प्रति CPU कोर प्रति सेकंड 1,470 सर्टिफिकेट (certificate), और 10 कोरों के आर-पार प्रति सेकंड 5,220 — यह अनुपात ही समांतरता का दावा है, जो प्रतिपादित नहीं बल्कि मापा गया है।
• हस्ताक्षर सत्यापन: प्रति सेकंड 1,500, एकल, small-order और torsion जाँचों सहित।
• आद्योपांत: 2,900 सर्टिफिकेट (certificate) का एक ब्लॉक 1,963 ms में validate होता है और 9.9 ms में fold होता है। दोनों अलग-अलग बताए गए हैं क्योंकि वे तर्क के दो आधे हैं: पहला उन कोरों के साथ स्केल करता है जो नेटवर्क के अपने नहीं हैं, दूसरा वह एकमात्र लूप है जो उसका अपना है।

Fold का मापन एक व्यवकलन है, और यह कहना उसे बताने का हिस्सा है: एक ब्लॉक कमिट करना stateless जाँचें और अनुक्रमिक fold साथ-साथ चलाता है, इसलिए fold का आँकड़ा पूरा घटा वे जाँचें है जिनका समय अलग से लिया गया। दोनों आधे कलाकृति में हैं।

हम केवल वही बताते हैं जो संदर्भ कार्यान्वयन चलाता है, और इससे दो सीमाएँ बनती हैं जिन्हें पाठक के खोजने के लिए छोड़ने के बजाय नाम देना उचित है। हस्ताक्षर सत्यापन एक बार में एक हस्ताक्षर मापा गया है: batch सत्यापन एक असली तकनीक है और स्पष्ट रूप से उपयुक्त है, पर वह सुरक्षा-महत्वपूर्ण क्रिप्टोग्राफी है जिसे इस परियोजना ने लिखा नहीं है, और जो कोड मौजूद ही नहीं उसका आँकड़ा कोई मापन नहीं है। §2 और §6 जिन GPU और SIMT आँकड़ों की प्रत्याशा करते हैं, वे sequencer के batch सर्टिफिकेट (certificate) के हैं, जो Era 1 के साथ आते हैं। दोनों डिज़ाइन अपेक्षाएँ हैं। ऊपर के आँकड़ों के लिए दोनों में से कोई भार-वाहक नहीं: समांतरता का दावा इस पर टिका है कि सर्टिफिकेट स्वतंत्र रूप से जाँचे जा सकते हैं, जिसे batching तेज़ तो बना सकती है पर सच नहीं बना सकती।

16. सम्बंधित कार्य#

Zycord की pipeline — पहले निष्पादन, फिर अंधा क्रम, कमिट पर validate — का एक पूर्वज अनुमति-आधारित परिवेशों में है: Hyperledger Fabric का execute-order-validate [3], जिसकी प्रलेखित कमज़ोरियाँ प्रतिस्पर्धा के अंतर्गत उसकी abort दर और संस्थागत endorsement नीतियों पर उसकी निर्भरता हैं। उस वंशावली के सापेक्ष Zycord के योगदान हैं (i) मान-समानता वाली applicability, जहाँ skip प्रथम-श्रेणी, ABA-सहिष्णु अर्थशास्त्र है; (ii) टकराव का आर्थिक आरोपण — bonded underwriting जो equivocation को वस्तुनिष्ठ रूप से slash-योग्य और बासीपन को एक मूल्यांकित, बीमा-योग्य सेवा बना देती है, यानी वही जिसकी कमी से execute-order-validate अनुमति-रहित न हो सका; और (iii) गारंटीशुदा अनुप्रयोग के साथ बलात् समावेशन, जहाँ rollup के निकास द्वार केवल समावेशन की गारंटी देते हैं। डिटरमिनिस्टिक पूर्व-घोषित read/write सेट Calvin [4] से उतरते हैं और Solana की access lists [16] में प्रकट होते हैं; क्रमविनिमेय escrow विधियाँ O'Neil [9] जितनी पुरानी हैं और आज Aptos aggregators over Block-STM [5] जैसे एकल-नोड schedulers के भीतर जीवित हैं — Zycord क्रमविनिमेयता अनुबंध को नोडों के बीच ले जाता है और उसका मूल्य लगाता है। समांतर-EVM सिस्टम [5] और स्थगित-निष्पादन चेन अब भी हर जगह पुनःनिष्पादन करते हैं और state-I/O की दीवार से टकराते हैं; Narwhal [6] डेटा वितरण को क्रम से अलग करता है जैसा हमारे शुरुआती डिज़ाइनों ने किया था; Sui की owned objects हमारे write-once cells के समांतर हैं; Zether [7] का pending/base विभाजन guarded-delta अनुशासन की प्रेरणा बना (और chimeric ledger की गोपनीयता जड़ों [8] के साथ §12 के गोपनीय भुगतानों में लौटता है — भारी-क्रिप्टो लेन का पहला किरायेदार, यानी छिपी राशियाँ और एक-बार-प्रयोग पते, जिनका मूल्य आधार परत में गढ़े जाने के बजाय समांतर gas में लगता है)। श्रृंखलित finality overlays Casper FFG [12] का अनुसरण करती हैं।

17. निष्कर्ष#

हमने एक ऐसा नेटवर्क प्रस्तावित किया है जो लेनदेन निष्पादित करने के बजाय सर्टिफिकेट (certificate) क्रमित करता है: validity को कोई भी, कहीं भी, समांतर में, केवल बाइट्स से जाँच सकता है; स्टेट को एक ऐसा fold आगे बढ़ाता है जो इतना सरल है कि एक पृष्ठ में विनिर्दिष्ट हो जाए; टकराव skip होते हैं, मूल्यांकित होते हैं, और उनके मालिक होते हैं; समवर्तिता खोजी नहीं बल्कि घोषित की जाती है; सेंसरशिप रचना से झेली जा सकती है; और एक ऐसा लॉन्च जो coin को बाँट देता है इससे पहले कि वह किसी से किसी validator समुच्चय पर भरोसा करने को कहे। सत्यापन उस हार्डवेयर के साथ बाहर की ओर स्केल करता है जो नेटवर्क का अपना नहीं है। कमिटमेंट अनुक्रमिक बना रहता है — और लगभग मुफ़्त।

Zycord काम के पीछे नहीं भागता। वह स्थिर रहता है, और काम नेटवर्क करता है।

सन्दर्भ#

[1] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008. [2] V. Buterin. Ethereum: A Next-Generation Smart Contract Platform. 2013. [3] E. Androulaki et al. Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains. EuroSys 2018. [4] A. Thomson et al. Calvin: Fast Distributed Transactions for Partitioned Database Systems. SIGMOD 2012. [5] R. Gelashvili et al. Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing. 2022. [6] G. Danezis et al. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus. EuroSys 2022. [7] B. Bünz, S. Agrawal, M. Zamani, D. Boneh. Zether: Towards Privacy in a Smart Contract World. Financial Cryptography 2020. [8] J. Zahnentferner. Chimeric Ledgers: Translating and Unifying UTXO-based and Account-based Cryptocurrencies. IACR ePrint 2018/262. [9] P. E. O'Neil. The Escrow Transactional Method. ACM TODS, 1986. [10] M. Herlihy, E. Koskinen. Transactional Boosting: A Methodology for Highly-Concurrent Transactional Objects. PPoPP 2008. [11] M. Shapiro et al. Conflict-free Replicated Data Types. SSS 2011. [12] V. Buterin, V. Griffith. Casper the Friendly Finality Gadget. 2017. [13] M. Corallo. BIP 152: Compact Block Relay. 2016. [14] tevador et al. RandomX: Proof-of-Work Algorithm Optimized for General-Purpose CPUs. 2019. [15] EIP-1559: Fee Market Change for the ETH 1.0 Chain. Ethereum Improvement Proposals, 2019. [16] A. Yakovenko. Solana: A New Architecture for a High Performance Blockchain. 2017. [17] Decred Documentation: Issuance. docs.decred.org — ब्लॉक इनाम का PoW miners, PoS मतदाताओं, और treasury के बीच विभाजन। [18] EIP-4844: Shard Blob Transactions. Ethereum Improvement Proposals, 2022. [19] Monero: Dynamic Block Weight and Penalty. Monero Research Lab दस्तावेज़ीकरण; JollyMort भी देखिए, Monero Dynamic Block Size and Dynamic Minimum Fee, 2017. [20] bitcoincashautist. CHIP-2023-04: Adaptive Blocksize Limit Algorithm for Bitcoin Cash. 2023.