आर्किटेक्चर

श्वेतपत्र का इंजीनियरिंग साथी — संदर्भ नोड डिज़ाइन को कैसे साकार करता है, और उसके पीछे के निर्णय। व्याख्यात्मक, मानक नहीं।

दो प्रिडिकेट, दो इंजन#

एक सर्टिफिकेट का जीवन, सिरे से सिरे तक:

 wallet or sequencer         network                        every full node
+-------------+   gossip   +--------------+               +---------------------+
| build cert  | ---------> | cert topic   | ------------> | STATELESS PIPELINE  |
| (reads,     |            | (TLS gossip) |               | V-rules, strict     |
| writes,     |            +--------------+               | Ed25519, program    |
| sigs, fee,  |                                           | re-execution        |
| deposit)    |                                           |  -> mark VALID      |
+-------------+                                           +----------+----------+
                                                                     | mempool
                                                                     v
                        miner (any node)                  +---------------------+
                      +----------------------+   block    | FOLD (sequential)   |
                      | order the hash list, | ---------> | per certificate:    |
                      | append forced certs, |   gossip   | APPLIED / SKIPPED / |
                      | RandomX solve        |            | FORCED_FAILED /     |
                      +----------------------+            | DROPPED -> state    |
                                                          +---------------------+

Validity stateless और समांतर है: वह प्रति नोड प्रति सर्टिफिकेट एक बार चलती है, ब्लॉकों से पहले और उनसे स्वतंत्र। Applicability stateful और अनुक्रमिक है: वह fold के भीतर सर्टिफिकेट की कमिट की गई स्थिति पर चलती है। माइनर को जो कुछ दिया जाता है उसमें से वह कुछ भी निष्पादित नहीं करता: वह उन हैशों को क्रमित करता है जिन्हें वह पहले ही validated देख चुका है और proof of work हल करता है, या, Era 2 में proof of stake पर switch के बाद, उस slot पर हस्ताक्षर करता है जिसके लिए वह ड्रॉ में चुना गया। निष्पादन का उसका एकमात्र अंश forced path का है, Era 1 से: वह अपने ब्लॉक के अंत की स्टेट के विरुद्ध open intents निष्पादित कर सकता है और परिणाम जोड़ सकता है, प्रति ब्लॉक अधिकतम 16, जिन्हें फिर हर नोड किसी भी अन्य सर्टिफिकेट की तरह जाँचता है। Fold एक in-memory कार्यकारी सेट पर एक कसा हुआ लूप है — तुलना, जोड़, write — और कुछ भी निष्पादित नहीं करता।

इंजीनियरिंग सिद्धांत#

P3 वह है जिस पर एक संशयी पाठक को सबसे ज़्यादा दबाव डालना चाहिए, और treasury वह जगह है जहाँ यह दबाव डालना चाहिए: genesis में न कोई कुंजी है और न कोई ख़र्च पथ, इसलिए रखने, सौंपने या चुराने के लिए कोई विशेषाधिकार ही नहीं है। Treasury ऊँचाई 259,200 से पहले ख़र्च नहीं की जा सकती, और उसे खोलने वाला जो भी नियम हो वह एक consensus परिवर्तन के रूप में आता है — वही सामाजिक तंत्र जो किसी भी अन्य परिवर्तन का है, उसी अस्वीकृति के अधीन, और तब भी ठीक एक cell को हिलाने में सक्षम। संस्थापक हिस्सा एक credit है, कुंजी नहीं: हर सब्सिडी का 3% पैरामीटर फ़ाइल में तय एक पते को, ऊँचाई 3,153,600 तक, जिसे Era 2 epoch 1,095 के रूप में पढ़ता है। वह पता कॉइन रखता है और किसी और चीज़ तक नहीं पहुँचता। एडमिन कुंजी वह है जो किसी की सहमति से पहले मौजूद हो और हर चीज़ तक पहुँचे।

क्रिप्टोग्राफ़िक प्रिमिटिव#

torsion अस्वीकृति ही बैच पथ को सुरक्षित बनाती है। मिश्रित-कोटि की कुंजी निम्न-कोटि की नहीं होती, इसलिए कोई blocklist उस तक नहीं पहुँचती, और ठीक वहीं cofactor वाला बैच सत्यापक और cofactor-रहित एकल सत्यापक असहमत होते हैं। कुंजी और R के अभाज्य-कोटि उपसमूह में होने पर दोनों सिद्ध रूप से समतुल्य हैं — इसलिए बैच सत्यापक cofactor वाला हो सकता है, बशर्ते वह बैच बनाने से पहले वही एन्कोडिंग और torsion नियम लागू करे। यह बाध्यता ही इस चुनाव की क़ीमत है, और बैच सत्यापक अभी मौजूद नहीं है।

कैनोनिकल एन्कोडिंग और पहचानकर्ता#

सभी consensus वस्तुएँ SSZ कंटेनर हैं: एक अकेली कैनोनिकल बाइट एन्कोडिंग, कोई map क्रम नहीं, वैकल्पिक-फ़ील्ड की कोई अस्पष्टता नहीं, सस्ते आंशिक पार्सिंग के लिए नियत ऑफ़सेट, और देशी merkleization।

cert_id       = blake3("zcd/certid/v1" || ssz(certificate with an empty signature list))
cert_exemplar = blake3("zcd/cert/v1"   || ssz(certificate))
block_id      = blake3("zcd/block/v1"  || ssz(header))

पहले दो अलग-अलग प्रश्नों का उत्तर देने वाले अलग digest हैं, और जो कार्यान्वयन एक को वहाँ इस्तेमाल करता है जहाँ दूसरा चाहिए वह मौद्रिक रूप से टूटा हुआ है। id इसका उत्तर देती है कि क्या इस अधिकार का बिल बन चुका है; exemplar हैश इसका कि क्या ये बाइट उसे सिद्ध करते हैं। दोनों कभी एक कुंजी साझा नहीं करते।

हस्ताक्षर id के preimage से बाहर हैं क्योंकि हस्ताक्षर एक यादृच्छिक प्रदर्शन है: nonce हस्ताक्षरकर्ता चुनता है, हर nonce उसी बॉडी पर एक और valid और बिलकुल कैनोनिकल हस्ताक्षर देता है, और कोई सत्यापक जाँच नहीं सकता कि कौन-सा इस्तेमाल हुआ। अगर वे भीतर होते, तो एक अधिकार की असीम रूप से कई id होतीं, हर एक बिल-योग्य, और हर एक उसके ज़रूरी हस्ताक्षरकर्ताओं में से किसी एक द्वारा बाक़ी के अधिकार से बनाई जा सकने वाली।

इससे निकलने वाला नियम: पार्स करो, दो बार वैधता मत जाँचो। डिकोडिंग कैनोनिकल रूप को लागू करती है, इसलिए डिकोड की गई वस्तु रचना से ही संरचनात्मक रूप से valid होती है और नियम-इंजन आकार दोबारा कभी नहीं जाँचते।

cell मॉडल#

एक cell किसी slot पर मौजूद मान है। cell के मान 32 बाइट में big-endian संग्रहीत अचिह्नित 256-बिट पूर्णांक होते हैं। अनुपस्थित cell शून्य के रूप में पढ़े जाते हैं — शून्य ही अनुपस्थिति है, और यह कार्यान्वयन की सुविधा नहीं बल्कि एक consensus अपेक्षा है: इससे state root उस स्टेट का फलन बना रहता है, न कि उस इतिहास का जिसने उसे बनाया।

अलग से, प्रोटोकॉल एक spent-address registry रखता है: उन one-shot पतों का स्थायी consensus समुच्चय जिनका हस्ताक्षर अधिकार जला दिया गया है।

Addr = version || blake3("zcd/addr/v1" || version || payload)[:31]

समानांतरता टाइप की गई पहुँच से आती है। एक read घोषित करता है कि वह अपने cell को कैसे बाँधता है — EXACT, या guards में से एक GUARD_GE, GUARD_LE, GUARD_EQ — और एक write घोषित करता है कि वह क्या करता है: SET, DELTA_ADD, DELTA_SUB या MARK_SPENT। केवल EXACT गणना को इनपुट देता है, और केवल EXACT ही cell के बदलने पर पुराना पड़ता है; guard कुछ नहीं लौटाता और delta कुछ नहीं पढ़ता, इसलिए पुनः-निष्पादन exact reads का शुद्ध फलन बना रहता है और एक slot पर कितने भी guarded डेबिट और क्रेडिट आपस में क्रम-निरपेक्ष (commute) रहते हैं। प्रति सर्टिफिकेट प्रति slot एक अनुशासन: set और delta कभी एक slot साझा नहीं करते। शून्य लिखना cell को मिटा देता है, इसलिए कभी न लिखा गया slot और शून्य लिखा गया slot एक ही slot हैं।

one-shot बनाम persistent एक वॉलेट नीति है जो पते के एक बिट के रूप में दिखती है, दो बहीखाते नहीं। वॉलेट डिफ़ॉल्ट रूप से हर आने वाले भुगतान के लिए एक नया one-shot address लेते हैं, जो बिना टकराव का रास्ता है; जिसे खाता चाहिए वह persistent संस्करण इस्तेमाल करता है। माइनिंग इनाम persistent पते में ही होने चाहिए: consensus भुगतान के रूप में दोनों प्रकार स्वीकार करता है, पर one-shot address जैसे ही ख़र्च होता है उसमें रखा हर इनाम जल जाता है, इसलिए नोड उसे अपने भुगतान पते के रूप में अस्वीकार करता है।

registry की प्रविष्टि कभी संकुचित नहीं की जाती। spent पते के तहत cell के मान undo horizon के बाद छाँटे जा सकते हैं, पर जो प्रविष्टि पते को spent दर्ज करती है वही उसे पुनर्जीवित होने से रोकती है। यह केवल-जोड़ी जाने वाली consensus स्टेट है, प्रति पता लगभग 33 बाइट, हमेशा के लिए — प्रोटोकॉल की ईमानदार खुली समस्या, जो हर nullifier-set डिज़ाइन के साथ संरचनात्मक रूप से साझा है।

स्टेटलेस वैधता, और बिलिंग नियम#

V-नियम हर सर्टिफिकेट पर, समानांतर में, mempool में प्रवेश से पहले और ब्लॉक सत्यापन के दौरान चलते हैं, और शून्य स्टेट माँगते हैं: कैनोनिकल रूप और chain id, हर सूची अपनी सीमा के भीतर; हर हस्ताक्षर signing root पर सख़्त Ed25519 के तहत सत्यापित, और हस्ताक्षर समुच्चय पर्याप्त होने के साथ-साथ न्यूनतम भी; घोषित reads के विरुद्ध प्रोग्राम का पुनः-निष्पादन ठीक-ठीक घोषित writes ही उत्पन्न करे; हर उस write के लिए प्राधिकरण जिसे उसकी ज़रूरत है, और deposit cell पर बिना शर्त एक हस्ताक्षर; एक ऐसा deposit जो किसी उपयोगकर्ता पते का मूल शेष हो और सर्टिफिकेट की सबसे बुरी स्थिति को ढकता हो; आत्म-संगति, ताकि कोई write उसी slot के read का खंडन न करे और कोई डेबिट किया गया one-shot address spent चिह्नित होने से न बचे; किसी protocol cell में कोई write नहीं; नामित हर पते पर एक परिभाषित संस्करण बाइट; और, जिस कॉन्ट्रैक्ट की sequencer कुंजी शून्य नहीं है उसमें, exact path पर उस कुंजी का हस्ताक्षर।

व्यवस्था का बिलिंग नियम एक वाक्य का है, और यही पकड़कर रखने लायक चीज़ है:

fold एक ब्लॉक को तीन वर्गों में क्रमबद्ध करता है और producer के लिए कोई विवेकाधिकार नहीं छोड़ता: पहले fills, उन sequencer pipelines के क्रम में जिनसे वे संबंधित हैं; फिर बाक़ी हर सर्टिफिकेट (deposit address, Seq, id) के अनुसार; अंत में forced सर्टिफिकेट, id के अनुसार। इसके बाद हर सर्टिफिकेट के ठीक चार में से एक परिणाम होता है, और golden vectors उनके नाम देते हैं:

लागू, skip और forced-failed सभी सर्टिफिकेट seen चिह्नित किए जाते हैं, और किसी seen, समाप्त या कम-बोली वाले सर्टिफिकेट को शामिल करना ब्लॉक को अमान्य बना देता है, ताकि कोई producer किसी और के सर्टिफिकेट को उसका deposit हड़पने के लिए दोबारा शामिल या विलंबित न कर सके। जिन विफलताओं के लिए शुल्क लेने को कोई नहीं है — ऐसा fill जिसका pipeline काउंटर क्रम से बाहर हो या जिसका fence counter खिसक गया हो, ऐसा forced सर्टिफिकेट जिसके reads टिके न हों — वे इसके बजाय ब्लॉक को अमान्य बना देती हैं: producer, जिसने ब्लॉक अपनी रखी हुई स्टेट से बनाया, वही पक्ष है जो यह जान सकता था।

Era द्वार#

सक्रियण ऊँचाइयाँ spec/params.json में रहती हैं। h1_vm = 80,640 Era 1 खोलता है: cEVM और पूर्व-तैनात लाइब्रेरी, sequencer कुंजी, admin और fence counter वाले कॉन्ट्रैक्ट रिकॉर्ड, intents और fills, directory, और forced path। Era के अपने स्थिरांक — 8-ब्लॉक की intent विंडो, प्रति ब्लॉक 16 forced सर्टिफिकेट जिनमें से हर एक 4,000 derivation इकाइयों का, directory प्रविष्टि का जीवनकाल जो उसकी घोषणा करने वाले सर्टिफिकेट के TTL के बाद 259,200 ब्लॉक है — पैरामीटर फ़ाइल द्वारा ढोए जाने के बजाय कंपाइल किए गए हैं, क्योंकि कोई पैरामीटर जोड़ने से हर जीवित नेटवर्क की genesis id बदल जाती; द्वार ब्लॉक उन्हें protocol cells में लिख देता है, इसलिए तब से state root उनके प्रति प्रतिबद्ध रहता है।

h1_bond mainnet पर और सार्वजनिक testnet पर h1_vm के बराबर है, इसलिए bonding संक्रियाएँ वहाँ कभी खुलती ही नहीं: Era 1 में कोई stake bonding नहीं है। Source tree अब भी v1.0 के underwriting, lease और forced-queue नियम रखता है, और वे केवल development नेटवर्क पर valid हैं, उसके h1_vm के ऊपर और उसके अपने v1 gate के नीचे 256 ब्लॉकों की एक विंडो में, जो इसलिए मौजूद है कि उस तंत्र को दर्ज करने वाले vectors के पास एक ऐसा नेटवर्क बना रहे जिस पर वह valid है। h2_pos = 1,576,800 proof of stake के लिए आरक्षित है, genesis पर जमाया गया और किसी नियम द्वारा नहीं पढ़ा जाता। Era 2, proof of stake, hard fork द्वारा अपनी अलग रिलीज़ के रूप में आता है, जिसके स्थिरांक Era 1 की तरह compile किए जाते हैं: वह ऊँचाई के आधार पर epoch 182 पर bonding खोलता है, अपना ramp तब शुरू करता है जब सक्रिय stake 30 epochs तक आपूर्ति का 10% रखे, या अधिकतम epoch 273 पर, और ramp पूरा होने पर 5-सेकंड slots पर switch करता है। Switch से वह हर उस genesis स्थिरांक को, जो वास्तव में एक अवधि है, उस इकाई में पढ़ता है जिसे वह मापता है, इसलिए पैरामीटर फ़ाइल नहीं बदलती।

रिपॉज़िटरी का ढाँचा#

zycord/
  spec/       parameter sets, golden vectors, library images   <- THE PROTOCOL
  core/       consensus-critical; standard library only (P4)
    types/  crypto/  ssz/  u256/  state/  validity/  fold/  params/  genesis/
    cevm/          the certificate-adapted EVM; vendored interpreter, pure Go
    stdlib/        the pre-deployed library, its addresses and code hashes
    pow/randomx/   the mainnet engine: vendored C++, cgo, behind a build tag
  node/       storage/  chain/  verify/  mempool/  miner/  p2p/  sync/  rpc/  stratum/
  wallet/     key management, certificate builders (reference; not consensus)
  contracts/  the reference contracts, in Solidity
  sim/        simulator, fuzz harnesses, differential refold, chaos soak
  cmd/        zycordd, zcd
  desktop/    the wallet in a native window — a separate Go module
  docs/       architecture, protocol, operating guide, whitepaper

निर्भरता के तीर केवल भीतर की ओर जाते हैं — node → core, wallet → core, कभी उल्टा नहीं — और core/ के भीतर कुछ भी core/ और मानक लाइब्रेरी के बाहर नहीं पहुँचता। एक अपवाद, नामित और प्रवर्तित: core/pow/randomx पेड़ का इकलौता cgo है, और वह केवल उस build tag के तहत कंपाइल होता है, इसलिए उस tag के बिना बना हर बिल्ड अब भी केवल मानक-लाइब्रेरी वाला है और उसे किसी C toolchain की ज़रूरत नहीं। इसे प्रवर्तित करने वाली जाँच CI चलाता है, क्योंकि तीसरे-पक्ष वाली जाँच मॉड्यूल पथ खोजती है और cgo के पास कोई पथ नहीं होता — जिससे यह नियम तब तक किसी से प्रवर्तित नहीं था जब तक वह जाँच जोड़ी नहीं गई।

इसका परीक्षण कैसे होता है#

• Golden vectors। हर fold, ब्लॉक और वैधता नियम के सकारात्मक और नकारात्मक मामले (pre-state, block) → (post-state | invalid, outcomes, fees) के रूप में हैं। यह सुइट स्वतंत्र कार्यान्वयनों के लिए संगतता अनुबंध है।
• griefing सुइट। लागू और skip हुए सर्टिफिकेट का दोबारा शामिल होना, समय-समाप्त शामिलीकरण, कम-बोली शामिलीकरण, proposer फेरबदल के तहत निर्भर शृंखलाएँ, जला-और-लौटा चक्र, तीसरे-पक्ष की क्रेडिट आँधियाँ, mint-सीमा पर सीमांत दौड़ें।
• गुण-आधारित। proposer-क्रम के क्रमचय के तहत fold की नियतता, delta की क्रम-निरपेक्षता, ABA सहनशीलता, और संरक्षण — जिसमें रास्ते में पड़ी जमा राशियाँ, maturity रिंग और treasury cell भी शामिल हैं, क्योंकि जो संरक्षण जाँच treasury को छोड़ देती है वह हर ब्लॉक को मूल्य गढ़ता हुआ बताती है।
• विभेदक। जानबूझकर भोला बनाया गया दूसरा fold कार्यान्वयन, जो गति के बजाय स्पष्टता के लिए लिखा गया है, असली वाले के विरुद्ध fuzz किया जाता है। दोनों में फ़र्क़ आना रिलीज़ रोक देता है।
• प्रतिकूल अनुकरण। skip की आँधियाँ, जमा-निचोड़ दौड़ें, drop भरने वाले माइनर, reorg यंत्रणा, टाइमस्टैम्प तोड़-मरोड़, हल्के eclipse relay परिदृश्य। परिदृश्य कॉन्फ़िग कमिट किए जाते हैं; रन seed से पुनरुत्पाद्य हैं।
• समवर्तिता, जानबूझकर। जिस भी घटक को एक से ज़्यादा goroutine छूती हैं उसका एक ऐसा परीक्षण है जो ख़ुद समवर्ती है, उसी आकार में जिसमें प्रक्रिया वास्तव में चलती है। एकल-goroutine सुइट पर -race कुछ नहीं मापता और सफलता बता देता है।
• अफ़रा-तफ़री वाला soak। असली नोड प्रक्रियाएँ, असली सॉकेट पर, ऐसी प्रॉक्सी के पीछे जो विलंब, jitter, हानि और विभाजन डालती है, और नोड को बेतरतीब SIGKILL से मारा जाता है। यही वह सतह है जिसने उस डेटा race को पकड़ा जिसे पूरा -race सुइट चूक गया था।

Genesis एक कलाकृति है, कोई समारोह नहीं#

zcd genesis genesis ब्लॉक निकालता है — ख़ाली स्टेट, आरंभीकृत beacon cell, ख़ाली spent registry, किसी भी तरह का कोई आवंटन नहीं — और उसकी id। लॉन्च पहले से कोड टैग, पैरामीटर हैश, genesis id और लॉन्च समय के प्रति प्रतिबद्ध था, और पैरामीटर समुच्चय में एक लॉन्च संदेश के प्रति प्रतिबद्धता थी जिसका digest ब्लॉक 1 को प्रकट करना था, ताकि कोई भी चेन को उसकी घोषित शुरुआत से पहले माइन न कर सके। कोई भी पहले चारों को स्रोत से, किसी भी मशीन पर, मिलीसेकंडों में दोबारा बना सकता है। भरोसा करने को और कुछ है ही नहीं।