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

Zycord: स्व-प्रमाणित स्टेट ट्रांज़िशन का एक पीयर-टू-पीयर नेटवर्क।
The Simstoshi
2026 — v2.0
GPG: E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29

यह पेपर पूर्ण और स्व-निहित है। यह v1.0 [0] का स्थान लेता है; §15 संबंध बताता है। लॉन्च, निर्गमन, Eras और पूरी पैरामीटर तालिका सहयोगी दस्तावेज़, Zycord: लॉन्च, Eras और पैरामीटर, में हैं।

संस्करण। नीचे का पाठ पेपर का v2.0 है, असंक्षिप्त, और इस पृष्ठ पर उसके बाद उसका सहयोगी दस्तावेज़ आता है, वह भी v2.0। दोनों PDF के रूप में परोसे जाते हैं, प्रत्येक के साथ प्रोजेक्ट कुंजी E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29 द्वारा बनाया गया एक पृथक हस्ताक्षर है: पेपर (हस्ताक्षर) और सहयोगी दस्तावेज़ (हस्ताक्षर)। हर संस्करण doi:10.5281/zenodo.22167489 के अंतर्गत संग्रहित है, जो नवीनतम संस्करण पर पहुँचाता है; प्रतिस्थापित v1.0 doi:10.5281/zenodo.22167490 है। सहयोगी दस्तावेज़ अपने अलग doi:10.5281/zenodo.23383987 के अंतर्गत संग्रहित है।

1. परिचय#

एक ब्लॉकचेन नोड तीन ऐसे काम करता है जिनमें कुछ भी समान नहीं: वह डेटा प्रसारित करता है, वह गणना सत्यापित करता है, और वह स्टेट को परिवर्तित करता है। डेटा bandwidth के साथ स्केल होता है। सत्यापन कोर के साथ स्केल होता है, और यदि लेनदेन स्वतंत्र रूप से जाँचे जा सकें तो वह पूर्णतः समांतर (embarrassingly parallel) है। स्टेट परिवर्तन ही एकमात्र वास्तव में अनुक्रमिक संसाधन है: कहीं न कहीं, writes का एक अकेला प्रामाणिक इतिहास मौजूद होना चाहिए।

Zycord तीनों को अलग करता है। एक लेनदेन एक सर्टिफिकेट बन जाता है जो अपने इनपुट और आउटपुट स्वयं ढोता है, इसलिए उसका सत्यापन उसके बाइट्स का एक शुद्ध फलन है और कभी लेजर को नहीं छूता। चेन का काम सिकुड़कर सर्टिफिकेटों को क्रमित करना और उन पर एक नियतात्मक fold चलाना रह जाता है: तुलनाओं और जोड़ों का एक लूप जो प्रति सर्टिफिकेट ठीक एक बार स्टेट को छूता है। टकराव ब्लॉकों को invalid नहीं करते; वे अलग-अलग सर्टिफिकेटों को skip करवाते हैं, और हर skip का शुल्क उस पक्ष से लिया जाता है जिसने जोखिम स्वीकार किया। Concurrency runtime पर खोजी नहीं जाती; उसे कॉन्ट्रैक्ट लेखक द्वारा slot दर slot घोषित किया जाता है। वंशावली है execute-order-validate [3], नियतात्मक क्रमण [4], आशावादी समांतर निष्पादन [5] और प्रसार का क्रमण से पृथक्करण [6]।

Validity प्रति सर्टिफिकेट एक बार चलती है, समांतर रूप से, किसी भी ब्लॉक के अस्तित्व में आने से पहले। Fold प्रति ब्लॉक एक बार चलता है, क्रम से, और कभी निष्पादन नहीं करता।

डिज़ाइन दो जगतों पर टिका है जो एक executable साझा कर सकते हैं पर जिन्हें कभी आपस में भ्रमित नहीं किया जाना चाहिए:

Consensus नियम केवल सत्यापन करते हैं। उनका उद्देश्य यह है कि कोई उपयोगकर्ता बिना अधिकृत किए धन न खोए, कोई ऐसे balance को debit न करे जिस पर उसका नियंत्रण नहीं, और कोई हमलावर नेटवर्क को खाली, अवरुद्ध या धीमा न कर सके। एक sequencer कैसे काम करता है, sequencers आपस में कैसे बात करते हैं और वे क्या शुल्क लेते हैं, यह consensus के बाहर है। जो on-chain है वह निपटान है: एक sequencer का भुगतान उस intent के भीतर यात्रा करता है जिस पर उपयोगकर्ता ने हस्ताक्षर किए, और उसका भुगतान केवल तभी होता है जब सर्टिफिकेट लागू होता है।

आगे के अनुभाग सर्टिफिकेट (§2), fold (§3), टाइप्ड स्टेट एक्सेस (§4), नेटिव एसेट (§5), वर्चुअल मशीन (§6), sequencers (§7), forced path (§8), दो fee मार्केट (§9), नेटवर्क (§10), proof of stake (§11), पूर्ण सत्यापन से आगे का मार्ग (§12), स्वीकृत जोखिम (§13), अनुरूपता (§14) और v1.0 से संबंध (§15) को परिभाषित करते हैं।

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

सर्टिफिकेट ही एकमात्र लेनदेन प्रकार है। यह SSZ-encoded है, जो एक canonical बाइट encoding देता है; decoding canonical रूप लागू करता है, इसलिए एक decoded सर्टिफिकेट रचना से ही संरचनात्मक रूप से valid है और कोई बाद का नियम आकार को फिर से नहीं जाँचता।

दो digests दो प्रश्नों का उत्तर देते हैं। सर्टिफिकेट id ख़ाली हस्ताक्षर सूची वाले सर्टिफिकेट का हैश है: यह उसका नाम देता है जिसे सर्टिफिकेट अधिकृत करता है। Exemplar hash पूरी encoding को ढकता है, हस्ताक्षरों सहित: यह बाइट्स के एक सेट का नाम देता है। हस्ताक्षर id से बाहर रहते हैं क्योंकि हस्ताक्षर करना यादृच्छिक है; हर nonce उसी body पर एक और valid हस्ताक्षर देता है, और जो id उन्हें ढकती वह एक अधिकृतीकरण को असीमित रूप से अनेक शुल्क-योग्य पहचानें दे देती। Id seen set, fold क्रम और सारे deduplication की कुंजी है। एक fill और एक forced सर्टिफिकेट अपने intent का हैश id के रूप में लेते हैं (§7, §8); एक fill की बोली उसके sequencer के हस्ताक्षर से मुहरबंद होती है। Exemplar hash वह है जिसके प्रति ब्लॉक का सर्टिफिकेट root प्रतिबद्ध है, इसलिए एक ब्लॉक id उन बाइट्स को निर्धारित करती है जिन्हें ब्लॉक ढोता है। Fee बोली id के भीतर है और हस्ताक्षरित है: id से बाहर की बोली ऐसी बोली है जिसे पारगमन में कोई भी फिर से लिख सकता है। हर हस्ताक्षर एक ऐसे संदेश पर होता है जो chain id और पैरामीटर सेट के consensus root को बाँधता है, इसलिए किसी सर्टिफिकेट को किसी दूसरे नेटवर्क पर replay नहीं किया जा सकता।

Validity stateless है। एक सर्टिफिकेट तब valid है जब, केवल उसके बाइट्स से:

1. वह canonical रूप से decode होता है, इसी चेन का नाम लेता है, और हर सूची अपनी सीमा के भीतर है;
2. हर हस्ताक्षर strict Ed25519 (canonical encodings, torsion-मुक्त कुंजियाँ) के अंतर्गत सत्यापित होता है, और हस्ताक्षर सेट पर्याप्त होने के साथ-साथ न्यूनतम भी है;
3. घोषित reads के विरुद्ध program को फिर से निष्पादित करने पर ठीक वही writes उत्पन्न होते हैं जो घोषित हैं;
4. हर write जिसे अधिकृतीकरण चाहिए उसके पास वह है, और deposit cell बिना शर्त एक हस्ताक्षर रखता है;
5. deposit एक user पते का नेटिव-balance cell है और सर्टिफिकेट की सबसे बुरी स्थिति को समेटता है;
6. सर्टिफिकेट स्व-संगत है: कोई write उसी slot के किसी read का खंडन नहीं करता, कोई debit किया गया one-shot address spent चिह्नित होने से नहीं बचता, और किसी spent पते पर कोई मान नहीं लिखा जाता;
7. वह कोई प्रोटोकॉल cell नहीं लिखता;
8. वह जिस भी पते का नाम लेता है, उसमें एक परिभाषित version बाइट है;
9. किसी ऐसे कॉन्ट्रैक्ट में जिसकी sequencer key शून्य नहीं है, exact-read path उस कुंजी का हस्ताक्षर रखता है (§7), सिवाय किसी forced सर्टिफिकेट के (§8);
10. एक metadata write हर उस cell का exact read घोषित करता है जिसे वह अधिलेखित करता है, उस मान पर जो सर्टिफिकेट बनाए जाते समय cell में था।

कोई भी मशीन इसे जाँचती है: एक थ्रेड पूल, कोई दूसरा कंप्यूटर, एक GPU, बिना किसी डेटाबेस के और बिना समकालन के। हस्ताक्षर जाँचें एक-दूसरे से स्वतंत्र हैं, इसलिए उन्हें सर्टिफिकेटों के आर-पार batch किया जा सकता है। यही वह गुण है जिस पर बाक़ी सब कुछ टिका है।

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

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

एक ब्लॉक एक header, सर्टिफिकेट exemplar hashes की एक क्रमित सूची, और स्वयं सर्टिफिकेट bodies है। Bodies चेन डेटा हैं: एक ब्लॉक तभी valid है जब उसकी bodies उपलब्ध हों। ब्लॉक का producer कुछ भी निष्पादित नहीं करता। वह उन सर्टिफिकेटों को क्रमित करता है जिन्हें वह पहले ही validated देख चुका है, proof of work [13] हल करता है (या, proof of stake के अंतर्गत, उस slot पर हस्ताक्षर करता है जिसके लिए वह ड्रॉ में चुना गया, §11), और TTL विंडो के भीतर देखी गई सर्टिफिकेट ids का सेट रखता है, क्योंकि किसी एक को दो बार शामिल करने से ब्लॉक invalid हो जाता है।

चेन की स्टेट क्रमित सर्टिफिकेटों पर एक fold है। हर सर्टिफिकेट के लिए, क्रम से, fold deposit आरक्षित करता है, हर घोषित read को वर्तमान स्टेट के विरुद्ध जाँचता है, जाँचे गए अंकगणित के साथ writes को stage करता है, और फिर कमिट या skip करता है:

• APPLIED — हर घोषित read टिका है, इसलिए writes उतरते हैं और fee वास्तविक लागत पर निपटती है।
• SKIPPED — कोई read अब टिका नहीं रहता (STALE), कोई delta सीमा [0, 2²⁵⁶) से बाहर चला जाता (OVERFLOW), या कोई write किसी spent पते के अंतर्गत उतरता (SPENT)। कुछ भी नहीं लिखा जाता। Deposit से एक नियत skip fee जलाई जाती है और शेष लौटा दिया जाता है।
• FORCED_FAILED — एक forced सर्टिफिकेट (§8) जिसका कॉल revert हुआ या जिसने अपने bounds तोड़े। उसके payers debit किए जाते हैं और राशि जला दी जाती है, change उपयोगकर्ता को लौटता है, और कुछ नहीं लिखा जाता, और id seen चिह्नित की जाती है।
• DROPPED — सर्टिफिकेट से शुल्क लिया ही नहीं जा सका (deposit cell में धन नहीं है या वह spent है), इसलिए उसे ढोया जाता है, seen चिह्नित किया जाता है और कोई शुल्क नहीं लिया जाता। वह अपने producer को कुछ नहीं देता और उसकी सीमा का स्थान खाता है। इसी स्थिति में एक fill इसके बजाय ब्लॉक को invalid कर देता है (नीचे), क्योंकि उसे drop करना उपयोगकर्ता के intent को बिना किसी को भुगतान हुए खपा देता।

Canonical क्रम। Fold किसी ब्लॉक के सर्टिफिकेटों को तीन वर्गों में क्रमित करता है और producer को कोई विवेकाधिकार नहीं छोड़ता। पहले fills (§7), हर एक जैसे ही वह हर pipeline, जिसमें वह है, तैयार हो, लिया जाता है, बराबरी (sequencer key, contract, seq, id) से तोड़ी जाती है। फिर अन्य सभी सर्टिफिकेट (deposit address, Seq, id) के अनुसार। अंत में forced सर्टिफिकेट (§8), id के अनुसार। हर नोड ब्लॉकों के एक समान अनुक्रम से एक समान स्टेट व्युत्पन्न करता है।

Writes उनमें से किसी के उतरने से पहले जाँचे जाते हैं। ऐसे पते पर credit जिसका अधिकार जलाया जा चुका है, cell को पुनर्जीवित करने के बजाय स्पष्ट रूप से विफल होता है; वह delta जो overflow करता, पूरे सर्टिफिकेट को विफल कर देता है। स्थायी spent registry ठीक इसी के लिए मौजूद है।

Skip अर्थ है, विफलता नहीं। समावेशन और अनुप्रयोग भिन्न घटनाएँ हैं। एक producer किसी ऐसे सर्टिफिकेट को शामिल करके कभी invalid ब्लॉक नहीं बना सकता जो बासी निकला; सर्टिफिकेट skip किया जाता है और depositor भुगतान करता है। Reads depositor ने चुने, इसलिए उनके लिए depositor ही उत्तरदायी है।

एक हस्ताक्षर, अधिकतम एक शुल्क। Applied और skipped सर्टिफिकेट, दोनों seen चिह्नित किए जाते हैं। किसी seen या समाप्त सर्टिफिकेट को, या किसी भी मार्केट में ब्लॉक की base fee से नीचे बोली लगाने वाले सर्टिफिकेट को शामिल करना ब्लॉक को invalid बनाता है, इसलिए कोई producer दूसरों के सर्टिफिकेटों को उनके deposits बटोरने के लिए फिर से शामिल या जानबूझकर विलंबित नहीं कर सकता। TTLs consensus द्वारा सीमित हैं, इसलिए seen set छाँटने योग्य बना रहता है।

जिन स्थितियों में शुल्क लेने को कोई नहीं है, वे ब्लॉक को invalid करती हैं। कुछ विफलताओं का कोई दोषी नहीं होता: ऐसा fill जिसका sequencer काउंटर क्रम से बाहर है, जिसका fence counter (§7) आगे बढ़ चुका है, जिसका payer पहले ही spent है या जिसका deposit आरक्षित नहीं किया जा सकता; ऐसा forced सर्टिफिकेट जिसके reads नहीं टिकते। ऐसे सर्टिफिकेट को शामिल करना ब्लॉक को invalid कर देता है और कोई शुल्क नहीं लिया जाता। Producer, जिसने अपने पास की स्टेट से ब्लॉक बनाया, वही पक्ष है जो यह जान सकता था।

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

मान की समानता, versions नहीं। Applicability घोषित read मानों की तुलना करती है, version काउंटरों की नहीं। जो slot बदला और फिर वापस बदल गया वह अब भी applicable है, इसलिए प्रणाली version-आधारित concurrency नियंत्रण की तुलना में कड़ाई से कम बार skip करती है।

Fold का अपना आरंभ और समापन। सर्टिफिकेटों से पहले, epoch सीमा पर, fold beacon cells (§4) लिखता है। उनके बाद, वह ब्लॉक subsidy को बाँटता है और coinbase maturity ring को घुमाता है (सहयोगी दस्तावेज़), fee नियंत्रक (§9) के लिए लागू gas दर्ज करता है और, epoch सीमा पर, epoch state root की गणना करता है, जो header वाले के बराबर होना चाहिए। वह त्रुटि केवल ब्लॉक की invalidity के लिए लौटाता है; किसी सर्टिफिकेट के साथ समस्या एक परिणाम है, कभी त्रुटि नहीं।

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

एक cell एक slot (address, word) पर स्थित मान है: एक 256-बिट unsigned पूर्णांक, 32 बाइट्स में big-endian। अनुपस्थित cells शून्य के रूप में पढ़े जाते हैं। Cells के साथ प्रोटोकॉल एक spent-address registry रखता है, उन one-shot addresses का एक स्थायी सेट जिनका हस्ताक्षर अधिकार जलाया जा चुका है।

एक पता version ‖ blake3(tag ‖ version ‖ payload)[:31] है, सिवाय प्रोटोकॉल पते के, जो version बाइट 0x00 और उसके बाद शून्य हैं:

One-shot बनाम persistent एक wallet नीति है जो पते के एक बिट के रूप में प्रकट होती है, दो लेजर नहीं [7]। Wallets डिफ़ॉल्ट रूप से हर आने वाले भुगतान के लिए एक नया one-shot address लेते हैं, इसलिए नए व्युत्पन्न पते पर भुगतान शून्य-होड़ वाला तेज़ पथ है, और एक spent cell तब संकुचित किया जा सकता है जब उसे ख़र्च करने वाला ब्लॉक undo horizon से परे दब चुका हो। जिसे खाता चाहिए वह persistent version इस्तेमाल करता है। माइनिंग इनाम एक persistent address पर होने चाहिए: consensus किसी भी प्रकार को payout पते के रूप में स्वीकार करता है, पर एक one-shot address उसके पास के हर इनाम को उसी क्षण जला देता है जब वह ख़र्च होता है, और इसी कारण नोड उसे अस्वीकार करता है।

समांतरता टाइप्ड एक्सेस से आती है। वह fold जो केवल exact reads का समर्थन करता, हर लोकप्रिय कॉन्ट्रैक्ट को क्रमबद्ध कर देता: एक pool को छूते हज़ार सर्टिफिकेट एक अनुप्रयोग और 999 skips देते। इसके बजाय, एक read घोषित करता है कि वह किसी cell को कैसे बाँधता है और एक write घोषित करता है कि वह उसके साथ क्या करता है:

केवल EXACT बासी होता है। एक slot पर कितने भी guarded debits और credits क्रमविनिमेय हैं: वे किसी भी क्रम में लागू होते हैं, और skip केवल तब होता है जब कोई guard वास्तव में विफल हो (एक वास्तविक overdraft), न कि जब balance केवल बदल गया हो। प्रति सर्टिफिकेट प्रति slot एक अनुशासन: एक set और एक delta एक ही slot पर साथ नहीं रहते। जो नियम मॉडल को सुदृढ़ रखता है वह यह है कि guarded मान कभी गणना में नहीं बहते: एक assert कुछ नहीं लौटाता और एक delta कुछ नहीं पढ़ता, इसलिए पुनःनिष्पादन घोषित exact reads का एक शुद्ध फलन बना रहता है। यह एक अनुशासन transfers, आपूर्ति-सीमित mints, allowances, tips और vault shares को ढकता है, जो on-chain writes का भारी बहुमत है। वंशावली है escrow transactions, transactional boosting और CRDTs [8][9][10]; Zycord क्रमविनिमेयता को नोडों के बीच का concurrency अनुबंध बनाता है।

One-shot cells। जो पता कभी चेन पर नहीं आया वह स्थिति ∅ में है; पहला write उसे stored में ले जाता है; वह सर्टिफिकेट जो उसे spent चिह्नित करता है, उसकी कुंजी से हस्ताक्षरित, उसे स्थायी रूप से spent में ले जाता है। ख़र्च दर्ज करने वाली registry प्रविष्टि कभी संकुचित नहीं की जाती: वही पते को पुनर्जीवित होने से रोकती है।

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

Epoch beacon। Programs को परिवेशी मान सीधे नहीं पढ़ने चाहिए। प्रोटोकॉल उस header की ऊँचाई, जिसने वर्तमान epoch खोला, और मशीन Era से उसका समय, आरक्षित cells में प्रति epoch एक बार लिखता है, और programs उन्हें किसी भी अन्य slot की तरह पढ़ते हैं। यह प्रति-ब्लॉक बासीपन के बिना समय-बोध देता है; दोनों मान पूरे epoch में स्थिर रहते हैं, mainnet पर एक दिन: proof of work के अंतर्गत 2,880 ब्लॉक, proof of stake के अंतर्गत 17,280 (§11)।

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

लॉन्च Era को कंप्यूटर से पहले एक अर्थव्यवस्था चाहिए। Zycord ब्लॉक 0 से नेटिव एसेट को सर्टिफिकेट संक्रियाओं के रूप में देता है, जिनमें कोई वर्चुअल मशीन शामिल नहीं:

• TRANSFER — एक सर्टिफिकेट में (asset, from, to, amount) की अधिकतम 32 चालें, उसकी reads और writes की सीमाओं के भीतर, हर एक दो deltas के साथ जोड़ा गया एक guard balance ≥ Δ। किसी pure delta पर या किसी नए one-shot cell पर लक्षित credit ही tip है, इसलिए tip देने को अपना कोई opcode नहीं चाहिए। किसी कॉन्ट्रैक्ट पते को केवल नेटिव coin से credit किया जा सकता है, और किसी precompile के पते (§6) को कभी नहीं, जिससे कुछ भी उस मान को बाहर नहीं निकाल सकता।
• ISSUE — एक बार-लिखे cell में आपूर्ति सीमा के साथ एक asset id बनाता है।
• MINT — guarded: minted + Δ ≤ cap।
• RETIRE — अधिकतम 64 one-shot addresses जलाता है, हर एक उसके मालिक द्वारा अधिकृत और सर्टिफिकेट की सीमाओं के भीतर, बिना मान हिलाए: कोई reads नहीं, एक pure write जो हर cell को spent चिह्नित करता है। वास्तविक ख़र्च transfer के भीतर स्वचालित है। Retirement संकुचन और गोपनीयता का primitive है: प्राप्तकर्ता काम पूरा होने पर one-shot address को मिटा देता है।

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

एक भुगतान इस तरह निपटता है। प्रेषक का wallet अपने पास का एक one-shot cell चुनता है, उस पर एक guard घोषित करता है, उसे debit करता है, उसे spent चिह्नित करता है, प्राप्तकर्ता के नए one-shot address को credit करता है और बाक़ी राशि (change) अपने ही एक नए one-shot address पर भेजता है। दो भिन्न नोडों के माध्यम से एक ही one-shot cell को spend करने की होड़ में लगे दो सर्टिफिकेट दोनों valid हैं; ठीक एक लागू होता है, और दूसरा skip होता है और उसका शुल्क उस deposit से लिया जाता है जिसका उसने नाम लिया।

6. मशीन: cEVM#

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

Storage घोषित किया जाता है, खोजा नहीं जाता। एक सर्टिफिकेट वे reads ढोता है जो उसके निष्पादन ने उपभोग किए और वे writes जो उसने उत्पन्न किए, और validity उनकी तुलना एक पुनःनिष्पादन से करती है। चार opcode परिवार किसी cell तक पहुँचते हैं: exact अनुशासन में SLOAD और SSTORE, और क्रमविनिमेय अनुशासन में assert और delta परिवार। एक कॉल किया गया frame घोषित सेट में अधिकतम 16 प्रविष्टियाँ जोड़ सकता है, इसलिए callee वे सीमाएँ ख़र्च नहीं कर सकता जो उसके caller को चाहिए; जो प्रविष्टि इससे अधिक होती वह उसी frame को रोकती है और किसी अन्य को नहीं।

जोड़े गए, उन बाइट्स पर जिन्हें किसी EVM fork ने कभी असाइन नहीं किया: SASSERTGE 0x21, SASSERTLE 0x22, SASSERTEQ 0x23, SDELTAADD 0x24, SDELTASUB 0x25, SETSEQ 0x26। प्रिडिकेट और चिह्न opcode में हैं, कभी stack पर नहीं। एक guard कुछ नहीं लौटाता, इसलिए कोई शाखा इस पर निर्भर नहीं हो सकती कि वह टिकता है या नहीं; एक delta का शुद्ध योग पूर्णांकों पर लिया जाता है और कभी 2²⁵⁶ modulo नहीं। SETSEQ(key) उस कॉन्ट्रैक्ट का sequencer cell set करता है जिसका context निष्पादित हो रहा है, और किसी अन्य का नहीं; एक शून्य या विकृत कुंजी एक व्युत्पत्ति विफलता है जो पूरे सर्टिफिकेट को invalid कर देती है।

पुनर्बंधित: NUMBER और TIMESTAMP epoch-beacon cells के exact reads से उत्तर देते हैं, इसलिए दोनों पूरे epoch में स्थिर रहते हैं, और एक port किया गया कॉन्ट्रैक्ट जो किसी समय-सीमा के लिए block.timestamp इस्तेमाल करता है वह 24 घंटे तक बासी समय के आधार पर निर्णय ले रहा है।

हटाए गए (13): BLOCKHASH, COINBASE, PREVRANDAO, GASLIMIT, BLOBHASH [14], BLOBBASEFEE, SLOTNUM का यहाँ कोई संदर्भ-वस्तु नहीं है; GASPRICE और BASEFEE प्रति-ब्लॉक cells का नाम लेते हैं जिनका exact read रचना से ही बासी है; BALANCE और SELFBALANCE किसी नेटिव balance का exact read बाध्य करते; ORIGIN के पास नाम लेने के लिए कोई प्रेषक नहीं है; SELFDESTRUCT किसी code-hash cell को शून्य पर लौटने देता।

पुनर्मूल्यांकित: SLOAD और SSTORE warm-access लागत पर सपाट हैं; cold-access अधिभार हर जगह हटा दिया गया है; KECCAK256 बढ़कर 720 gas और प्रति word 144 हो जाता है, इस मशीन के अपने कार्यान्वयन के विरुद्ध मापा गया, वह एकमात्र पुनर्मूल्यांकन जो कोई शुल्क बढ़ाता है। Assert और delta opcodes की लागत SLOAD जितनी ही warm-access राशि है।

Precompiles पाँच का एक बंद सेट हैं: sha256, identity, modexp, ed25519_verify और blake3।

दो मीटर। Sequential gas घोषित read, write और registry गणनाओं से व्युत्पन्न होती है और मशीन द्वारा कभी मापी नहीं जाती। समांतर मीटर वह है जिसे interpreter गिनता है, उस बजट के विरुद्ध जिसे सर्टिफिकेट व्युत्पत्ति इकाइयों (derivation units) में घोषित करता है; depth 0 पर उससे अधिक होना सर्टिफिकेट को invalid कर देता है।

कोड सर्टिफिकेट में यात्रा करता है। कॉन्ट्रैक्ट कोड एक-बार-लिखे code-hash cell में रहता है, इसलिए कोई पुनः-deploy नहीं है, और एक deploy शून्य लक्ष्य वाला एक कॉल है। Runtime image सर्टिफिकेट में साथ चलती है और code-hash cell के एक घोषित exact read से resolve होती है, कभी केवल पते से नहीं। एक blob अधिकतम 24,576 बाइट्स का होता है।

किसी कॉन्ट्रैक्ट का रिकॉर्ड पाँच cells है: code hash, deployer, sequencer key, admin और fence counter (§7)। Admin cell एक पता रखता है; शून्य का अर्थ है कि deployer ही admin है, और 0xff के 32 बाइट्स का अर्थ है कि भूमिका अपरिवर्तनीय रूप से त्याग दी गई है। Admin एक registration सर्टिफिकेट के माध्यम से sequencer key set करता है और एक set-admin सर्टिफिकेट के माध्यम से भूमिका आगे सौंपता है या त्यागता है; दोनों deployer और admin cells के exact reads घोषित करते हैं, इसलिए किसी बदले गए या त्यागे गए admin का सर्टिफिकेट skip होता है। कॉन्ट्रैक्ट कोड कभी admin set नहीं करता; वह SETSEQ से अपना sequencer बदलता है, और इसी तरह factory द्वारा बनाया गया कॉन्ट्रैक्ट एक sequencer पाता है।

मानक लाइब्रेरी। एक token, एक tip jar और एक escrow, delta-first लिखे गए, मशीन को सक्रिय करने वाले ब्लॉक में ज्ञात पतों पर पहले से deploy किए जाते हैं, उस delta wrapper के साथ जिसे वे कॉल करते हैं। एक port किया गया Ethereum कॉन्ट्रैक्ट जो हटाए गए opcodes और precompiles से बचता है, पहले दिन से all-exact मोड में सही चलता है, यदि वह गर्म है तो एक sequencer द्वारा क्रमबद्ध; समांतरता प्रति slot opt-in है, आमतौर पर एक छोटा diff जो एक balance map को load/store से assert/delta पर ले जाता है।

7. Sequencers#

Guarded deltas भुगतानों की होड़ को घोल देते हैं। जो बचता है वह गर्म स्टेट पर exact-read तर्क है, एक order book, एक automated market maker, जहाँ एक ही cell के विरुद्ध बनाने वाले दो ईमानदार उपयोगकर्ता फिर भी एक skip उत्पन्न करेंगे, और जहाँ वे कॉन्ट्रैक्ट जो क्या लिखना है यह तय करने के लिए स्टेट पढ़ते हैं, मनमाने क्रम में लागू नहीं किए जा सकते। प्रोटोकॉल का उत्तर है कॉन्ट्रैक्ट को अपना serializer चुनने देना।

बंधन। हर कॉन्ट्रैक्ट का रिकॉर्ड (§6) एक sequencer key रखता है। जिस कॉन्ट्रैक्ट की key शून्य नहीं है वह sequenced है: कोई सर्टिफिकेट उसके cells में से किसी का exact read, समानता guard या set केवल उस key के हस्ताक्षर से कर सकता है। जिस कॉन्ट्रैक्ट की key शून्य है वह open है: कोई भी अपने स्वयं के सर्टिफिकेट से उसका exact path ले सकता है, और कॉन्ट्रैक्ट केवल अपने कोड से सुरक्षित है। Key deploy के समय deployer द्वारा set की जाती है, बाद में admin द्वारा, या कॉन्ट्रैक्ट के अपने कोड द्वारा SETSEQ के माध्यम से, और इसी तरह एक governance बिना admin के sequencer बदलती है। बंधन किसी भी key का नाम ले सकता है; जिस key को कोई सेवा नहीं देता वह consensus त्रुटि नहीं है, कॉन्ट्रैक्ट बस तब तक अनुपयोगी है जब तक कोई उसे सेवा न दे या forced path (§8) उसे बदल न दे। Guarded deltas क्रमविनिमेय हैं और कभी gated नहीं होते, इसलिए एक sequenced token अब भी किसी से भी हर transfer स्वीकार करता है।

Directory। एक sequencer एक directory सर्टिफिकेट से घोषणा करता है कि उसकी सेवा कहाँ उत्तर देती है: उसकी key और मुद्रण-योग्य ASCII के 1 से 256 बाइट्स की एक string, आमतौर पर एक URL, एक persistent address से घोषित। नवीनीकरण न होने पर प्रविष्टि घोषणा करने वाले सर्टिफिकेट के TTL के 90 दिन बाद समाप्त हो जाती है, और एक withdrawal सर्टिफिकेट उसे तुरंत हटा देता है। Consensus string को संग्रहीत करता है और कभी उसकी व्याख्या नहीं करता। Directory खोज है, अधिकृतीकरण नहीं: wallets उसे यह जानने के लिए पढ़ते हैं कि किससे पूछें।

Intents। उपयोगकर्ता किसी sequenced कॉन्ट्रैक्ट के विरुद्ध सर्टिफिकेट नहीं बनाता। उपयोगकर्ता एक intent पर हस्ताक्षर करता है: लक्ष्य और calldata, एक समांतर बजट, एक nonce, NotBefore से TTL तक की एक विंडो जिसमें TTL − NotBefore अधिकतम 8 ब्लॉक, sequencer का persistent address, परिणाम पर bounds का एक सेट, sequencer को देय भुगतान, किसी भी co-sequencers को देय भुगतान, one-shot payers जो यह सब धन देते हैं, और change outputs। एक bound उस cell पर एक प्रिडिकेट है जिसे कॉल लिखता है, final-at-least, final-at-most, delta-at-least या delta-at-most, और कम से कम एक bound को उस slot का नाम लेना होगा जिसे कॉल ने लिखा। Intent उपयोगकर्ता का पूरा अधिकृतीकरण है; sequencer यह नहीं बदल सकता कि वह क्या करता है, केवल कब।

Fills। Sequencer intent को स्टेट के अपने दृष्टिकोण पर निष्पादित करता है, यानी चेन का शीर्ष और हर वह fill जिसे वह पहले ही बना चुका है, और परिणाम को एक fill के रूप में प्रकाशित करता है: एक सर्टिफिकेट जिसका program intent है, जिसका deposit sequencer के अपने persistent balance से आता है, और जिसकी id intent का हैश है, इसलिए एक intent के दो fills एक ही id साझा करते हैं और केवल एक से शुल्क लिया जा सकता है। Sequencer पर केवल liveness के लिए भरोसा किया जाता है, सुरक्षा के लिए कभी नहीं: यदि वह इनपुट के बारे में झूठ बोलता है, तो fill canonical fold के विरुद्ध बस skip हो जाता है, और झूठ की क़ीमत sequencer का deposit चुकाता है, उपयोगकर्ता का धन नहीं।

Receipts। एक sequencer किसी हस्ताक्षरित intent का उत्तर मिलीसेकंडों में देता है, किसी ब्लॉक के अस्तित्व में आने से बहुत पहले: वह intent निष्पादित करता है, fill पर हस्ताक्षर करता है, और wallet को fill लौटाता है, या intent id, pipeline seq और परिणाम का नाम लेने वाली एक हस्ताक्षरित receipt। यह एक पूर्व-पुष्टि है। यह sequencer का वादा है, चेन का नहीं; यह fill के लागू होने पर अंतिम होती है। क्योंकि हर receipt हस्ताक्षरित है, दुर्व्यवहार प्रमाण है: एक key की दो receipts जो एक seq को भिन्न intents को देती हैं, या एक intent को भिन्न परिणाम, एक ऐसा प्रमाण हैं जिसे कोई भी बाइट्स से जाँच सकता है। Consensus इसे दंडित नहीं करता। मार्केट करता है। Receipt का प्रारूप, मूल्य, पहचान और प्रतिष्ठा off-chain हैं और डिज़ाइन से स्वतंत्र, इसलिए उपयोगकर्ता एक सस्ते sequencer, एक सार्वजनिक रूप से पहचाने गए या एक अनाम sequencer के बीच चुनते हैं, और उसे छोड़ देते हैं जो equivocation करते पकड़ा जाए।

Pipelines। चेन हर जोड़ी (sequencer key, contract) के लिए अंतिम लागू seq रखती है। एक fill हर उस pipeline के लिए एक seq घोषित करता है जिसमें वह है और तभी प्रवेश कर सकता है जब काउंटर seq − 1 पर हो; काउंटर तभी आगे बढ़ते हैं जब fill लागू हो। इसलिए एक skip हुआ fill अपने काउंटर को वहीं छोड़ देता है जहाँ वह था: उसके पीछे बने fills प्रवेश नहीं कर सकते, और sequencer उसी संख्या से फिर बनाता है। एक seq पर दो fills: fold क्रम में पहला प्रवेश करता है, दूसरा नहीं कर सकता। किसी sequencer की pipeline उसी क्रम में कमिट होती है जिसमें उसने हस्ताक्षर किए, producer ने उसे किसी भी क्रम में पाया हो, और कई sequencers की pipelines को मिलाने वाले producer के पास परिणाम पर कोई विकल्प नहीं है।

Fence counter। हर कॉन्ट्रैक्ट अपने रिकॉर्ड में एक काउंटर, fid, रखता है। एक fill हर उस कॉन्ट्रैक्ट का fid घोषित करता है जिसे वह exact पढ़ता है या set करता है; बेमेल होने का अर्थ है कि fill प्रवेश नहीं कर सकता। काउंटर एक से आगे बढ़ता है जब लागू होने वाला कोई forced सर्टिफिकेट (§8) कॉन्ट्रैक्ट का कोई cell set करता है, और जब कॉन्ट्रैक्ट का sequencer cell लिखा जाता है। एक read या एक delta उसे आगे नहीं बढ़ाता: read कुछ नहीं बदलता, और delta उसके साथ क्रमविनिमेय है जिसे कोई fill guard करता है या जिस पर delta लगाता है। जो fill ऐसा cell exact पढ़ता है जिसे दूसरे delta से हिलाते हैं, वह उस read के लिए किसी भी सर्टिफिकेट की तरह उत्तरदायी है, और cell हिलने पर उसका sequencer skip का भुगतान करता है। इसी तरह forced path और sequencer परिवर्तन हर उस fill को invalid करते हैं जो उस स्टेट पर बना था जिसे उन्होंने दरकिनार किया, बिना किसी से शुल्क लिए: sequencer fence को खिसकते देखता है, फिर बनाता है और फिर प्रकाशित करता है, केवल latency खोते हुए।

Co-sequencing। जो कॉल अलग-अलग sequencers से बँधे कॉन्ट्रैक्टों को पार करती है वह चेन पर एक fill के रूप में उतरती है जिस पर हर उस sequencer का हस्ताक्षर होता है जिसके exact path को वह छूती है, सर्टिफिकेट की 16 हस्ताक्षरों की सीमा के भीतर, हर एक ब्लॉक की हस्ताक्षर सीमा के विरुद्ध और parallel gas में गिना जाता है, हर एक का अपनी pipeline में एक seq, हर एक को वह भुगतान जो intent उसके लिए नामित करता है। समन्वय, कौन नेतृत्व करता है, आरक्षण कैसे होते हैं, हर एक क्या शुल्क लेता है, off-chain है और डिज़ाइन से स्वतंत्र; चेन एक सर्टिफिकेट देखती है, रचना से atomic। एक संयुक्त fill जो कभी प्रकाशित नहीं होता केवल उन pipelines को अवरुद्ध करता है जिनमें वह है; उसकी विंडो बीत जाने पर हर हस्ताक्षरकर्ता उस संख्या का पुनः उपयोग करता है जिस पर उसने हस्ताक्षर किया था।

Skip का भुगतान कौन करता है। जब कोई fill प्रवेश करता है और कोई read बासी है या कोई write overflow करता है, तो कुछ नहीं लिखा जाता, किसी को भुगतान नहीं होता, और जिसने ग़लती की वह skip fee चुकाता है: सर्टिफिकेट क्रम में विफल होने वाला पहला read या write निर्णय करता है, और बिल उस sequencer को जाता है जिसने उस कॉन्ट्रैक्ट के लिए स्वयं को घोषित किया, यदि कॉन्ट्रैक्ट fill के exact path पर है और चेन का रिकॉर्ड सहमत है; हर अन्य स्थिति में वह leader को जाता है, वह sequencer जिसके deposit का fill नाम लेता है। हर सूचीबद्ध sequencer का एक reserve fill की स्थिति पर ठीक इसी के लिए लिया जाता है। उपयोगकर्ता कभी skip का भुगतान नहीं करता। हर sequencer को उपयोगकर्ता का भुगतान तभी निपटता है जब fill लागू हो।

Sequencer क्या है। एप्लिकेशन टीम द्वारा चलाया जाने वाला एक साधारण सर्वर, जिसमें जो भी व्यवस्था उसे पसंद हो: एक अकेली प्रक्रिया, एक rollup, एक federation। वह अपने एप्लिकेशन का order flow सबसे पहले देखता है और इसलिए उस एप्लिकेशन के निकाले जा सकने वाले मूल्य (extractable value) का स्वाभाविक स्थल है; डिज़ाइन इसे स्पष्ट करता है और एप्लिकेशन को वह मूल्य block producers को रिसने देने के बजाय स्वयं पकड़ने देता है, जबकि forced path इससे निहित शक्ति को सीमित करता है। भारी कॉन्ट्रैक्ट व्यवहार्य हो जाते हैं, क्रिप्टोग्राफी, किसी गेम का पूरा तर्क, एक कॉन्ट्रैक्ट में एक पूरा सिस्टम, क्योंकि भारी निष्पादन निर्माण के समय off-chain होता है और चेन उसे समांतर रूप से सत्यापित करती है। निर्माण एक प्रतिस्पर्धी मार्केट है: एक सस्ता या अधिक विश्वसनीय sequencer उपयोगकर्ताओं को आकर्षित करता है, और निर्माण प्रदान करने वाला हर नोड क्षमता बढ़ाता है।

8. Forced path: समावेशन ही अनुप्रयोग है#

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

उपयोगकर्ता एक open intent पर हस्ताक्षर करता है: ठीक §7 जैसा एक intent, जिसमें न किसी sequencer का नाम है और न co-sequencers का, जिसे उपयोगकर्ता के अपने one-shot payers धन देते हैं, और उसे नेटवर्क पर relay करता है। यह mempool में intent के रूप में यात्रा करता है, सर्टिफिकेट के रूप में नहीं। Block producer, जो पूरी स्टेट रखता है और ब्लॉक के हर साधारण सर्टिफिकेट को पहले ही निपटा चुका है, ब्लॉक-के-अंत की स्टेट की गणना करता है और अपनी चुनी हुई open intents को उस स्टेट के विरुद्ध, intent-id क्रम में, निष्पादित करता है, परिणामी forced सर्टिफिकेटों को ब्लॉक के अंतिम सर्टिफिकेटों के रूप में जोड़ते हुए। Forced सर्टिफिकेट की id उसके intent का हैश है, जैसे fill की। समावेशन ही अनुप्रयोग है: न कोई queue, न lease, न कोटा और न deadline। जिस forced सर्टिफिकेट के घोषित reads उस स्टेट के विरुद्ध नहीं टिकते जहाँ उसे रखा गया, वह ब्लॉक में प्रवेश ही नहीं कर सकता; producer ने उसे बनाया, इसलिए producer ही वह पक्ष है जो जान सकता था।

रचना से सीमित। एक ब्लॉक अधिकतम 16 forced सर्टिफिकेट ढोता है, और हर एक समांतर बजट की अधिकतम 4,000 व्युत्पत्ति इकाइयाँ (derivation units) घोषित करता है (200,000 machine gas)। कॉन्ट्रैक्ट द्वारा दिया गया हर निकास, withdrawal, cancellation, retirement, transfer, उस बजट में समाना चाहिए; कॉन्ट्रैक्ट लेखकों के लिए नियम है कि एक withdrawal forced बजट में समाता है। पूर्ण भराव पर forced path genesis समांतर सीमा का एक तिहाई लेता है और साधारण ट्रैफ़िक बाक़ी रखता है।

विफल होता कॉल भी उतरता है। जिस forced सर्टिफिकेट का कॉल revert होता है, अपने bounds तोड़ता है या gas से बाहर चला जाता है, वह अपने विफल रूप, FORCED_FAILED, में प्रवेश करता है: उसके payers debit किए जाते हैं और राशि जला दी जाती है, change उपयोगकर्ता को लौटता है, id seen चिह्नित की जाती है, और कुछ और नहीं लिखा जाता। Validity विफल रूप को तभी स्वीकार करती है जब घोषित reads के विरुद्ध कॉल का पुनःनिष्पादन वास्तव में विफल हो। यही पथ को दुरुपयोग के प्रति प्रतिरोधी बनाता है: एक हमलावर जो ऐसी open intents relay करता है जो सफल नहीं हो सकतीं, हर एक के लिए भुगतान करता है, और जिस उपयोगकर्ता का intent ठीक है उसे उनके कारण भूखा नहीं रखा जा सकता, क्योंकि producer को जो वह शामिल करता है उसके लिए भुगतान मिलता है और वह अधिशेष पसंद करता है।

Fence। जो forced सर्टिफिकेट लागू होता है और किसी कॉन्ट्रैक्ट का cell set करता है, वह उस कॉन्ट्रैक्ट के fence counter (§7) को आगे बढ़ाता है, इसलिए उसके द्वारा बदली गई स्टेट पर बना हर fill प्रवेश नहीं कर सकता। जो forced सर्टिफिकेट किसी sequenced कॉन्ट्रैक्ट को केवल पढ़ता है, exact या guards के माध्यम से, या उसमें केवल deltas हिलाता है, वह fence को नहीं छूता, और वह भी नहीं जो अपने विफल रूप में उतरता है; लंबित fills फिर भी प्रवेश करते हैं, और केवल वह skip होता है जिसने वह cell exact पढ़ा जिसे forced सर्टिफिकेट ने हिलाया (§7)। Sequencer latency खोता है, इससे अधिक कुछ नहीं, और जो उपयोगकर्ता किसी गर्म कॉन्ट्रैक्ट पर प्रति ब्लॉक एक लेनदेन force करता है वह हर बार forced मूल्य चुकाता है।

भुगतान। Intent का भुगतान ब्लॉक की base fees पर सर्टिफिकेट की fees को समेटता है; base-fee भाग जलाया जाता है और बाक़ी producer के tips में जुड़ता है। Producer को वही मिलता है जो एक sequencer को मिलता।

कोई स्टेट अनाथ नहीं होती। जिस कॉन्ट्रैक्ट का sequencer ग़ायब हो गया है वह अपनी delta विधियों के माध्यम से जीवित रहता है, जिन्हें किसी sequencer की ज़रूरत नहीं, और forced path के माध्यम से, जिससे उसके उपयोगकर्ता धन निकालते हैं और जिससे उसका अपना कोड, या admin, SETSEQ या एक registration कॉल कर सकता है और उसे एक नए sequencer से बाँध सकता है। सेंसरशिप उलट जाती है: इसकी क़ीमत सेंसर करने वाला चुकाता है, खोई fees में और उसे दरकिनार कर रास्ता बदलते उपयोगकर्ताओं में, और नेटवर्क को इसकी कोई क़ीमत नहीं चुकानी पड़ती। सुरक्षा के लिए कोई ऑपरेटर भार-वाहक नहीं है।

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

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

Sequential gas स्टेट परिवर्तन का मूल्य तय करती है, जो दुर्लभ संसाधन है, वह एकमात्र लूप जिसे हर नोड क्रम से चलाता है। Parallel gas सत्यापन का मूल्य तय करती है, जो नेटवर्क से जुड़ने वाले हर कोर और GPU के साथ बढ़ता है, और उसकी सीमा ऊँची और सस्ती रखी गई है। परिणाम एक अपरिवर्ती के रूप में कहा गया डिज़ाइन लक्ष्य है: भारी क्रिप्टोग्राफी नेटवर्क को प्रभावित नहीं करती, आर्थिक रचना से। वह सर्टिफिकेट जो एक बड़ा प्रमाण सत्यापित करता है पर दो slots लिखता है, लगभग सब कुछ सस्ते मार्केट में चुकाता है।

दोनों मार्केटों का आकार EIP-1559 जैसा है [12], हर एक अपनी इकाई में: base fee जलाई जाती है और priority fee producer को भुगतान करती है, उन सर्टिफिकेटों पर जो लागू होते हैं, और केवल उन्हीं पर। किसी skip हुए सर्टिफिकेट की fee पूरी जला दी जाती है और किसी को भुगतान नहीं करती। यह आर्थिक मॉडल का भार-वाहक नियम है। यदि skip से tip मिलता, तो ब्लॉक की सामग्री चुनने वाले पक्ष को दूसरों की विफलताओं की व्यवस्था करने के लिए भुगतान मिलता। जलाना इसे उलट देता है: एक skip सीमा का स्थान खाता है और कुछ नहीं देता, इसलिए राजस्व अधिकतम करने वाला producer अनुप्रयोग अधिकतम कर रहा है और skips उत्पन्न करने के सक्रिय रूप से विरुद्ध है।

केवल लागू gas base fees को हिलाती है। प्रति ब्लॉक तीन मात्राएँ गिनी जाती हैं: शामिल gas (हर सर्टिफिकेट, उसका परिणाम जो भी हो) सीमाओं को बाँधती है; लागू gas (केवल जो लागू हुआ) base fees को हिलाती है; ब्लॉक बाइट्स बाइट सीमा को बाँधते हैं। एक skip चेन के उपयोग का एक विफल प्रयास है, उसकी माँग का प्रमाण नहीं; यदि शामिल gas fee को हिलाती, तो एक griefer ब्लॉकों को नियत skip fee पर स्व-विरोधी सर्टिफिकेटों से भर सकता था और स्थिर लागत पर सबको मूल्य से बाहर कर सकता था।

अनुक्रमिक सीमा लचीली है। अनुक्रमिक लक्ष्य T ब्लॉक 0 से consensus स्टेट है, कोई स्थिरांक नहीं, और एक epoch नियंत्रक उसे हिलाता है:

• एक ब्लॉक के भीतर, नरम सीमा 2T है और कठोर सीमा 4T। जो producer दोनों के बीच उछाल करता है, वह अपने ही राजस्व का एक द्विघाती अंश गँवाता है, सब्सिडी का भाग और ब्लॉक की fees, और कभी किसी और का अंश नहीं।
• Epochs के पार, T माँग का अनुसरण करता है: epoch में लागू gas के निचले median का दोगुना, T − T/1024 और T + T/512 के बीच सीमित, genesis मान पर तल और genesis क्षमता पर ऊपरी सीमा के साथ (सहयोगी दस्तावेज़)। जब health gate कहता है कि नेटवर्क स्वस्थ नहीं है तो वृद्धि रोकी जाती है: epoch के ब्लॉकों के 2% से अधिक पर उद्धृत प्रतिस्पर्धी headers।
• सर्टिफिकेट गणना, हस्ताक्षर गणना और बाइट सीमा अपने genesis मानों से T के साथ स्केल होती हैं, स्थिर क्षमताओं तक (2²⁵ सर्टिफिकेट, 8 MB)।

Skip हुए सर्टिफिकेट अपनी fees जलाते हैं और कुछ दर्ज नहीं करते, इसलिए सीमा बढ़ाने का एकमात्र तरीक़ा अनुप्रयोग जीतना है: निरंतर, ग़ैर-विरोधी, base-fee जलाने वाला उपयोग। वृद्धि को बाध्य करना हमलावर को ठीक उतना ही ख़र्च कराता है जितना जैविक अपनाव बाक़ी सबको। समांतर मार्केट को इस सावधानी की ज़रूरत नहीं: उसका लक्ष्य और उसकी सीमा अनुक्रमिक लक्ष्य और सीमा के एक स्थिर गुणज, 3×, पर पिन हैं, इसलिए 3T और 6T, और वे उनकी वृद्धि विरासत में पाते हैं। वंशावली है Monero का penalty median [15] और adaptive-limit कार्य [16]।

निर्माण मार्जिन। वही समांतर मार्केट sequencers को काम को आकार देने का भुगतान करता है: एक sequencer जो अनेक लेनदेनों को एक सर्टिफिकेट में समुच्चित करता है, उसके लिए एक समांतर बोली चुकाता है और intent के भीतर अपने उपयोगकर्ताओं से प्रति लेनदेन शुल्क लेता है।

10. नेटवर्क#

Bodies चेन डेटा हैं। ब्लॉक के valid होने के लिए उसके सर्टिफिकेट bodies प्राप्त करने योग्य होने चाहिए, इसलिए स्टेट हमेशा केवल चेन से पुनर्निर्मित की जा सकती है और कोई ऑपरेटर, sequencer सहित, कभी डेटा संरक्षक नहीं होता। सर्टिफिकेट पारंपरिक लेनदेनों से बड़े हैं क्योंकि वे अपने reads और writes ढोते हैं; शमन संरचनात्मक हैं: fills आंतरिक writes को काट देते हैं, spent one-shot cells undo horizon से परे दबने पर संकुचित होते हैं, और एक नोड उस तल के नीचे bodies छाँट सकता है जिसे वह peers को घोषित करता है।

Transport। TCP, फिर TLS 1.3, जिसमें Ed25519 peer पहचानें स्व-हस्ताक्षरित सर्टिफिकेटों में होती हैं: चैनल एक कुंजी से बँधा है, और इससे अधिक कोई दावा नहीं किया जाता। हर संदेश एक 5-बाइट frame है, लंबाई और प्रकार, और किसी भी आवंटन से पहले लंबाई को प्रकार की अपनी सीमा के विरुद्ध जाँचा जाता है। किसी नए build द्वारा जोड़ा गया प्रकार कनेक्शन बंद करने के बजाय एक छोटी सीमा के अंतर्गत पढ़कर छोड़ दिया जाता है।

Relay hash-पहले है। सर्टिफिकेट स्वतंत्र रूप से gossip होते हैं और आगमन पर, stateless रूप से और समांतर रूप से, validity के लिए जाँचे जाते हैं। एक relay नोड को spam छानने की लागत सीमित करने के लिए किसी स्टेट की ज़रूरत नहीं: stateless validity बाइट्स से जाँची जा सकती है, और स्टेट रखने वाला नोड उस सर्टिफिकेट को भी अस्वीकार करता है जिसका deposit उसे ढक नहीं सकता। Relay exemplars से व्यवहार करता है, ids से नहीं: जिस सर्टिफिकेट के हस्ताक्षर विफल होते हैं उसकी क़ीमत वह exemplar चुकाता है, और id के विरुद्ध कुछ दर्ज नहीं किया जाता, क्योंकि उसी अधिकृतीकरण का कोई बाद का exemplar ठीक हो सकता है। ब्लॉक mempool [11] के विरुद्ध headers और हैश सूचियों के रूप में relay होते हैं, इसलिए प्रसार latency ब्लॉक सामग्री के साथ स्केल नहीं होती, और प्राप्तकर्ता कोई भी body लाने से पहले header का work सत्यापित करता है।

Sync सत्यापित work के आधार पर चुनता है। पीछे छूटा नोड उस peer को पसंद करता है जिसके headers ने वास्तव में सबसे अधिक work सिद्ध किया है, उस peer की तुलना में जो सबसे बड़ी ऊँचाई का दावा करता है। Bodies लाए जाने से पहले headers को एक चेन के रूप में validate किया जाता है; एक प्रतिस्पर्धी शाखा केवल तब अपनाई जाती है जब वह undo horizon के भीतर जुड़ती है और उस चेन से अधिक work रखती है जिसकी वह जगह लेती है (proof of stake के अंतर्गत, अधिक slots, §11)। Pinned checkpoints, जो रिलीज़ में अंतर्निहित हैं और केवल तब स्वीकार किए जाते हैं जब ब्लॉक कम से कम एक epoch पुराना हो, किसी विरोधी चेन को अस्वीकार करते हैं चाहे वह कितनी भी भारी हो, इतिहास के पुनर्लेखन के विरुद्ध लॉन्च-काल के बचाव के रूप में; एक ऑपरेटर flag द्वारा एक pin जोड़ सकता है।

Peers को अंक दिए जाते हैं, पहचान के अनुसार: एक invalid संदेश की क़ीमत 20 है, एक प्रोटोकॉल उल्लंघन की 50, एक न परोसे गए शरीर की 10, एक अत्यधिक अनुरोध की 5; एक उपयोगी संदेश 1 कमाता है; −100 पर peer प्रतिबंधित होता है। महँगी जाँचें, key epochs और proof of work मूल्यांकन, प्रति peer बजट में रखी जाती हैं और ब्लॉक उपयोगी सिद्ध होने पर लौटा दी जाती हैं, ताकि एक हमलावर किसी नोड से ऐसी घोषणाओं पर work न पिसवा सके जो कहीं नहीं ले जातीं।

उद्धरण। एक header अपने parent की ऊँचाई पर अधिकतम चार हाल के प्रतिस्पर्धी headers उद्धृत कर सकता है, बिना भुगतान के: उद्धृत करने के लिए वास्तविक proof of work चाहिए, जबकि संकेत को दबाने के लिए लगभग हर producer को उसे छोड़ना पड़ता। उद्धृत fork दर वह health संकेत है जिसे fee नियंत्रक (§9) पढ़ता है।

नोड इंटरफ़ेस। Reads HTTP पर परोसे जाते हैं, डिफ़ॉल्ट रूप से localhost से बँधे; सर्टिफिकेट, open intents और हस्ताक्षरित service cards जमा करना ही एकमात्र writes हैं। Reads प्रति क्लाइंट दर-सीमित हैं, ऑपरेटर के अपने टूल्स को छूट देने के लिए एक trust token के साथ। सामान्य CPU माइनर जिस बोली में बात करते हैं उसमें एक Stratum endpoint किसी नोड को बाहरी सॉफ़्टवेयर से माइन करने देता है।

11. Proof of stake#

यह अनुभाग उस Era के consensus को विनिर्दिष्ट करता है जिसमें ब्लॉक उत्पादन proof of work से stake पर जाता है। §2 से §10 तक के नियम अपरिवर्तित रहते हैं, सिवाय जहाँ यह अनुभाग अन्यथा कहे; अनुसूची और हर मान सहयोगी दस्तावेज़ में हैं। खुला चिह्नित स्थिरांक उस Era की रिलीज़ द्वारा तय किए जाते हैं।

क्या बदलता है। दो चीज़ें। अगला ब्लॉक बनाने का अधिकार, जिसे proof of work hashes के बदले बेचता है, stake के आधार पर ड्रॉ किया जाता है; और ब्लॉक अंतराल 30 से घटकर 5 सेकंड हो जाता है। बाक़ी सब बना रहता है: §2 का हर validity नियम हर नोड द्वारा, हर सर्टिफिकेट के लिए, बाइट्स से जाँचा जाता है; fold वही है; दोनों gas मार्केट वही हैं; ब्लॉक के भीतर एक invalid सर्टिफिकेट ब्लॉक को invalid बनाता है। §10 का उद्धरण नियम बना रहता है, उद्धृत header के work की जगह उसके slot हस्ताक्षर के साथ। यह Era जो सतह खोलता है वह एक proof of stake की सतह है, और कोई अन्य नहीं।

गणना कहाँ जाती है। एक proof-of-work माइनर hashes पर गणना ख़र्च करता है, जो सुरक्षा ख़रीदते हैं और कुछ नहीं। इस Era में एक producer वही गणना सत्यापन पर ख़र्च करता है: हस्ताक्षर जाँचना, programs को पुनःनिष्पादित करना, सर्टिफिकेट व्युत्पन्न करना, समांतर रूप से, उन्हें क्रमित करने से पहले। जिस काम के लिए नेटवर्क भुगतान करता है वह वही काम बन जाता है जिसकी नेटवर्क को ज़रूरत है। एक साधारण कंप्यूटर प्रति ब्लॉक हज़ारों सर्टिफिकेट सत्यापित करता है; अधिक कोर वाला producer मात्रा बढ़ने के साथ बराबर चलता रहता है। समांतर सत्यापन सीमा को उससे बहुत ऊपर रखता है जितना अनुक्रमिक लूप उपभोग करता है; उससे आगे जो है वह §12 में है।

Stake। एक भागीदार एक नेटिव संक्रिया, BOND, से नेटिव coin bond करता है, जो balance को एक persistent address से उस पते से बँधे एक stake cell में ले जाती है। Stake cells प्रोटोकॉल cells हैं: सर्टिफिकेट इस स्थानांतरण को अधिकृत करता है और fold write करता है, जैसे वह sequencer काउंटरों के लिए करता है। उस पते की कुंजी वही कुंजी है जो ब्लॉकों पर हस्ताक्षर करती है। एक stake bond किए जाने के एक epoch बाद सक्रिय होता है, इसलिए stakes को एक के बाद एक बनाया और त्यागा नहीं जा सकता; UNBOND undo horizon से लंबे विलम्ब के बाद balance लौटाता है। न्यूनतम सहयोगी दस्तावेज़ द्वारा तय किया जाता है। एक कुंजी, एक stake।

ड्रॉ (draw)। ब्लॉक एक नियत अंतराल के slots घेरते हैं। हर slot के लिए, epoch के आरंभ पर सक्रिय stakes के सेट से एक producer ड्रॉ किया जाता है, stake के अनुपात वाली संभावना के साथ, उस seed से जिसे चेन ने पिछले epoch के दौरान तय किया और beacon cells (§4) में लिखा; seed को उसे तय करने वाले ब्लॉकों के producers द्वारा प्रभावित (bias) नहीं किया जा सकना चाहिए। Header proof of work की जगह slot और ड्रॉ किए गए producer का हस्ताक्षर ढोता है; किसी अन्य कुंजी द्वारा हस्ताक्षरित, या अपने slot से बाहर का header invalid है। बिना ब्लॉक वाला slot ख़ाली रहता है, और अगला ड्रॉ किया गया producer उस अंतिम ब्लॉक पर बनाता है जिसे वह जानता है। ड्रॉ epoch खुलने से पहले तय स्टेट का एक फलन है, इसलिए हर नोड उसे अकेले व्युत्पन्न करता है, और स्वयं ब्लॉक से परे कोई consensus संदेश आदान-प्रदान नहीं होता। वंशावली है Ouroboros की slot-leader lottery [17] और Solana का प्रति-epoch leader schedule [21]; leader को एक verifiable random function [31] के पीछे छिपाना, जैसा Praos करता है [18], वह विकल्प है यदि ज्ञात producers के विरुद्ध denial of service एक समस्या बन जाए।

चेन का चुनाव। जहाँ §10 सत्यापित work के आधार पर चुनता है, यह Era लंबाई के आधार पर चुनता है: valid चेनों में से, वह जो सबसे अधिक slots घेरती है [17]; समान लंबाई की दो में से, वह जिसका fork के बाद का पहला ब्लॉक पहले वाले slot में है। §10 का undo horizon और pinned checkpoints बने रहते हैं और तब से unbond हो चुकी कुंजियों से पुनर्लेखन के विरुद्ध बचाव हैं: नेटवर्क से जुड़ने वाला नोड वह इतिहास स्वीकार करता है जिसे उसकी रिलीज़ pin करती है, और कोई लंबी चेन उसका खंडन नहीं करती।

इनाम। ब्लॉक सब्सिडी और priority fees ड्रॉ किए गए producer को जाती हैं, जैसे वे माइनर को जाती थीं, उसी maturity ring के माध्यम से; जला हुआ भाग जला हुआ ही रहता है। किसी भागीदार का अपेक्षित राजस्व उसके stake के अनुपात में है, और उसे एकत्र करने की लागत उन सर्टिफिकेटों का सत्यापन है जिन्हें वह शामिल करता है। एक invalid ब्लॉक अस्वीकार किया जाता है और जिसने भी उस पर हस्ताक्षर किए उसे कुछ नहीं देता।

Equivocation (दोहरा हस्ताक्षर)। Consensus में केवल एक ग़लती दंडित होती है: एक कुंजी द्वारा एक slot के लिए हस्ताक्षरित दो headers। एक invalid सर्टिफिकेट की तरह यह एक-संदेश का प्रमाण है, जिसे कोई भी बाइट्स से जाँच सकता है। एक report सर्टिफिकेट दोनों headers ढोता है; fold हस्ताक्षरकर्ता का अपना bond जलाता है, कुंजी को सक्रिय सेट से हटाता है और reporter को एक खुला अंश देता है। एक report तब तक स्वीकार किया जाता है जब तक stake का निकास पूरा न हो। Consensus में कोई अन्य आचरण दंडित नहीं होता, और किसी producer का कोई आचरण किसी और के coin तक नहीं पहुँचता। मिसाल है Ethereum की beacon chain पर proposer slashing [19]।

Pools। Pool एक ऐसा stake है जो delegation स्वीकार करता है। कोई भी persistent address bond कर सकता है और, एक नेटिव संक्रिया DELEGATE से, अपने bond को किसी pool की कुंजी की ओर इंगित कर सकता है; जो bond केवल delegate करता है उसका न्यूनतम उससे छोटा है जो उत्पादन करता है। Balance कभी delegator को नहीं छोड़ता, जो उसी निकास विलम्ब के अंतर्गत उसे पुनर्निर्देशित या unbond करता है। ड्रॉ में किसी pool का भार उसका अपना bond और उसे delegate की गई राशि है। किसी pool द्वारा बनाए गए ब्लॉकों का इनाम fold द्वारा प्रति epoch एक बार, प्रति-ब्लॉक पथ से बाहर, pool, उस margin पर जिसे वह पंजीकरण के समय घोषित करता है, और उसके delegators के बीच, stake के अनुपात में, बाँटा जाता है। Equivocation पर pool का अपना bond जलाया जाता है और उसकी delegations उनके delegators को लौट जाती हैं। Pool के भीतर सत्यापन कैसे साझा होता है यह pool का मामला है: हर सदस्य उसे मिला हिस्सा सत्यापित करता है, एक सर्टिफिकेट एक से अधिक सदस्यों को जा सकता है, और ऑपरेटर उत्तरों को मिलाता है, ब्लॉक जोड़ता है और ड्रॉ की गई कुंजी से उस पर हस्ताक्षर करता है। यह सब निर्माण है, consensus से बाहर और डिज़ाइन से स्वतंत्र (§1): चेन delegations की एक तालिका, एक कुंजी द्वारा हस्ताक्षरित एक header, और एक ऐसा ब्लॉक देखती है जिसके सर्टिफिकेटों को हर पूर्ण नोड फिर से सत्यापित करता है। एक छोटा नोड अपने पास के कोर का योगदान देता है; केवल coin वाला धारक stake का योगदान देता है। वंशावली है Cardano के stake pools [20], जो इसी तरह कभी delegators पर slashing नहीं करते।

Ramp। यह Era तीन चरणों में प्रवेश करता है, हर एक consensus नियम।

1. Bonding। BOND, UNBOND और DELEGATE स्वीकार किए जाते हैं। Proof of work हर ब्लॉक बनाता रहता है और producer का पूरा हिस्सा पाता रहता है।
2. Ramp, 90 epochs में। हर ब्लॉक अब भी माइन होता है, और उसकी ऊँचाई के लिए ड्रॉ किए गए stake का हस्ताक्षर ढोता है, header में proof-of-work preimage के बाहर; ब्लॉक id उसे ढकती है, इसलिए एक हस्ताक्षरित ब्लॉक और उसकी बिना हस्ताक्षर की प्रति दो ब्लॉक हैं, और समान work पर हस्ताक्षरित ब्लॉक जीतता है। चेन का चुनाव अब भी work के आधार पर है, और एक ऊँचाई पर दो हस्ताक्षर equivocation नहीं हैं। सब्सिडी में producer का हिस्सा माइनर और staker के बीच बँटता है: एक काउंटर k 1 से शुरू होता है और gate पार करने वाले हर epoch के साथ एक बढ़ता है, और staker k/180 लेता है, इसलिए switch तक work कम से कम आधा रखता है। हस्ताक्षर के बिना ढोया गया ब्लॉक valid है और किसी को भुगतान नहीं करता: सब्सिडी में उसका producer हिस्सा और उसकी priority fees जला दी जाती हैं, इसलिए माइनर को staker को बाहर छोड़ने से कुछ नहीं मिलता, और staker को अनुपस्थित रहने से कुछ नहीं मिलता। एक epoch gate पार करता है जब उसके कम से कम 90% ब्लॉकों ने हस्ताक्षर ढोया और सक्रिय stake ने, delegations सहित, आपूर्ति का कम से कम 10% रखा। Ramp तब शुरू होता है जब सक्रिय stake 30 epochs तक आपूर्ति के 10% तक पहुँचता है या, सबसे देर से, उस epoch पर जिसे सहयोगी दस्तावेज़ तय करता है, जो भी stake मौजूद हो उसके साथ। कोई ब्लॉक केवल stake द्वारा तब तक नहीं बनता जब तक stake ने, उत्पादन में, 90 epochs तक दस में से नौ ब्लॉकों पर हस्ताक्षर न किए हों। मिसाल है Decred का hybrid, जिसमें माइन किए गए ब्लॉक stake votes ढोते हैं और सब्सिडी दोनों के बीच बँटती है [22], और the Merge, जिसमें stake ने ब्लॉक उत्पादन सँभालने से पहले लगभग दो वर्ष तक अपनी चेन चलाई [23]।
3. Switch (संक्रमण)। Gate पार करने वाले 90वें epoch के बाद वाले epoch का पहला ब्लॉक slot 0 है: proof of work समाप्त होता है, अंतराल 5 सेकंड हो जाता है और epoch 17,280 slots का हो जाता है। एक epoch सब्सिडी में जो देता है वह नहीं बदलता; हर ब्लॉक छठा भाग देता है, और ख़ाली slot कुछ नहीं देता। प्रति-ब्लॉक सीमाएँ (§9), अपने तलों और ऊपरी सीमाओं के साथ, और forced-path गणना (§8) छह से विभाजित होती हैं, नीचे की ओर गोल, ताकि switch के क्षण प्रति दिन क्षमता वही रहे, और epoch नियंत्रक वहाँ से आगे चलता है। समय मापने वाला हर ब्लॉक-गणना स्थिरांक (maturity, अधिकतम TTL, intent विंडो, undo horizon, median-time विंडो, directory प्रविष्टि का जीवनकाल) छह से गुणा होता है, और switch से पहले set की गई maturity या TTL switch ब्लॉक पर परिवर्तित की जाती है।

अंतिमता (finality)। एक ब्लॉक गहराई से अंतिम होता है, जैसे proof of work के अंतर्गत। वित्तीय सेवाओं को 10 मिनट प्रतीक्षा करनी चाहिए: 120 ब्लॉक, जहाँ proof of work 20 माँगता था। एक epoch से पुराने ब्लॉकों को checkpoints के रूप में pin किया जा सकता है।

12. पूर्ण सत्यापन से आगे#

Proof-of-work और proof-of-stake Eras में हर नोड हर सर्टिफिकेट सत्यापित करता है। गणना सीमा नहीं है: सत्यापन समांतर है, और §9 की सीमाएँ Era सीमाओं पर सर्टिफिकेट सूची की संरचनात्मक चौड़ाई, प्रति ब्लॉक 2²⁵, तक फिर से पिन की जाती हैं। उस दीवार से पहले जो सीमित करता है वह डेटा है: हर body प्राप्त करने के लिए bandwidth और हर body तथा spent registry की हर प्रविष्टि रखने के लिए storage। यह अनुभाग बताता है कि उससे आगे के मार्ग के बारे में क्या ज्ञात है और उसे एक बाद के Era पर छोड़ता है, जो माँग पर सक्रिय होगा, जब दैनिक मात्रा उतने के क़रीब पहुँचे जितना एक साधारण नोड सत्यापित करता है। यह एक दिशा है, विनिर्देश नहीं: समस्याओं के कई समाधान हैं जिनके अलग-अलग trade-offs हैं, नेटवर्क लंबे समय तक उनमें से किसी के बिना हर उस माँग को पूरा करता है जिसका वह सामना करेगा, और दूर के भविष्य के लिए विस्तार से तैयारी करना उस मार्ग को, जो भी उस पर चले उसके लिए, चिह्नित छोड़ देने से अधिक मूल्यवान नहीं है। इससे पहले आने वाला कुछ भी नहीं बदलता। बाइट्स के फलन के रूप में validity, fold, टाइप्ड एक्सेस, दोनों मार्केट, sequencers और forced path जैसे हैं वैसे ही रहते हैं। केवल यह बदलता है कि हर सर्टिफिकेट को कौन सत्यापित करता है।

सर्टिफिकेट क्या संभव बनाता है। पुनःनिष्पादन वाली चेनों में, Ethereum, Solana और उनसे व्युत्पन्न चेनें, हर validator हर लेनदेन को वैश्विक स्टेट के विरुद्ध निष्पादित करता है, सत्यापन स्टेट की सीमाएँ विरासत में पाता है, और ऐतिहासिक उत्तर बड़ी मशीनें रहा है, यानी कम नोड। नोड के भीतर समांतर निष्पादन, Solana [21] की तरह घोषित access lists के साथ, हर मशीन को तेज़ बनाता है और यह नहीं बदलता कि किसे मशीन चाहिए। Cardano अधिक क़रीब आया: extended UTXO मॉडल में validation नियतात्मक और स्थानीय है [24], पर scripts हर नोड पर चलती हैं और साझा स्टेट में होड़ होती है, जिसे मॉडल serialization को off chain batchers पर धकेलकर हल करता है, जिन्हें चेन मान्यता नहीं देती। Rollups, optimistic और validity दोनों [25][26], ने निष्पादन को base chain से हटा दिया और उसे सत्यापन करते छोड़ा: यही सही विभाजन है, जिसकी क़ीमत एक दूसरी परत, एक bridge, एक अकेले sequencer, जिसका forced path एक विलम्ब के पीछे प्रतीक्षा करता है, और, प्रकार के अनुसार, एक सप्ताह के interactive विवाद या एक ऐसे prover से चुकाई जाती है जिसकी लागत निष्पादन से कई परिमाण-क्रम अधिक है। Zycord सर्टिफिकेट एक rollup batch है जिसे base chain अपने बाइट्स से जाँचती है और कभी अपनी स्टेट के विरुद्ध निष्पादित नहीं करती, और इसी कारण उसे किसी दूसरी परत की ज़रूरत नहीं: कोई bridge नहीं क्योंकि स्टेट एक है; कोई विवाद नहीं क्योंकि एक invalid सर्टिफिकेट स्वयं अपना fraud proof है, एक संदेश में; कोई prover नहीं क्योंकि सत्यापन की लागत उतनी ही है जितनी निष्पादन की; sequencer प्रति कॉन्ट्रैक्ट है, forced path अगले ब्लॉक में उतरता है, और अलग-अलग sequencers के अंतर्गत दो कॉन्ट्रैक्ट एक atomic सर्टिफिकेट (§7) में जुड़ते हैं, जहाँ दो rollups को एक bridge चाहिए। और जहाँ वृद्धि का उत्तर sharding है, Ethereum का मूल प्रक्षेप-पथ, Near [27], parachains [28], जो स्टेट को विभाजित करता है और विभाजनों के पार atomicity खो देता है, वहाँ Zycord का विभाजन, जब आएगा, सत्यापन को विभाजित करता है, स्टेट को नहीं: स्टेट एक रहती है, fold एक रहता है और हर सर्टिफिकेट atomic रहता है, क्योंकि जब validity बाइट्स का फलन है तो किसी सर्टिफिकेट को कौन सत्यापित करता है यह एक स्वतंत्र चुनाव है।

नमूना सत्यापन (sampled verification)। Bonded stake के साथ, किसी सर्टिफिकेट को सत्यापित करने का दायित्व सभी stakes पर पड़ने के बजाय stakes के एक उपसमुच्चय पर ड्रॉ किया जा सकता है। एक सर्टिफिकेट अपनी committee की attestations के साथ ब्लॉक में प्रवेश करता है; कोई भी नोड कुछ भी सत्यापित करने के लिए स्वतंत्र रहता है; एक invalid सर्टिफिकेट स्वयं अपना fraud proof बना रहता है, एक संदेश, बिना स्टेट और बिना interactive खेल के [29]; और यह Era जो जोड़ता है वह है जिसने भी attest किया उसकी slashing। Committee का आकार, attestation का रूप, challenge विंडो, और किसी रद्द सर्टिफिकेट के ऊपर जो लागू हुआ उसका क्या होता है, ये उस Era का विनिर्देश हैं, और खुले रहते हैं। प्रभाव वक्र को उलटना है: क्षमता जुड़ने वाले हर नोड के साथ बढ़ती है, क्योंकि हर एक छोटा हिस्सा सत्यापित करता है, और committee सेट के साथ बढ़ती है।

सत्यापन शंकु (verification cone)। जो कोई सर्टिफिकेट प्राप्त करता है उसे उस पर भरोसा करने के लिए पूरी चेन की ज़रूरत नहीं। Reads घोषित हैं, इसलिए जिन सर्टिफिकेटों पर वह निर्भर है उनका सेट चेन से गिना जा सकता है: पढ़े गए हर cell के लिए, वे सर्टिफिकेट जिन्होंने उसे अंतिम epoch state root के बाद लिखा, और उनके, पुनरावर्ती रूप से। वह शंकु, बाइट्स से पुनःसत्यापित और उस epoch root पर आधारित जिसके प्रति header प्रतिबद्ध है (§3), प्राप्तकर्ता के लिए जो मायने रखता है उसका पूर्ण सत्यापन है, सेकंडों में, नेटवर्क समय में, बिना किसी circuit और बिना किसी विशेष proof के। Deposit प्राप्त करने वाला exchange deposit का शंकु सत्यापित करता है, नेटवर्क का नहीं; नमूना सत्यापन के अंतर्गत जो बचता है वह reorgs और challenge विंडो के बीतने की प्रतीक्षा है, जो वह आज पहले से करता है। यह प्रमाण कि epoch root पर किसी cell का एक दिया गया मान था, वह एकमात्र नई वस्तु है जिसकी इसे ज़रूरत है, और उसका रूप खुला है; वंशावली है simplified payment verification [1]।

Storage। नेटवर्क पहले से क्या करता है: spent one-shot cells undo horizon (§4) से परे संकुचित होते हैं, और एक नोड उस तल के नीचे bodies छाँटता है जिसे वह घोषित करता है (§10)। अध्ययन के विषय के रूप में क्या बचता है: प्रति epoch एक spent registry, जिसमें one-shot addresses समाप्त होते हैं और registry बंद होती है; registry की जगह एक accumulator [30]; और नोडों के एक अंश द्वारा पुरानी bodies रखना, epoch root को इस गारंटी के रूप में लेकर कि जो रखा गया है वही है जो ख़र्च हुआ था।

Bandwidth। दो मार्ग। पहला वह topology है जो डिज़ाइन में पहले से है: wallet, sequencer, producer। एक fill को नेटवर्क में बाढ़ की तरह फैलने की ज़रूरत नहीं; वह sequencer से producers तक जाता है, और बाक़ी सब हैश प्राप्त करते हैं, जैसा relay पहले से ब्लॉकों के साथ करता है (§10)। दूसरा है किसी सर्टिफिकेट के head को उसकी body से अलग करना। Head वह है जिसे fold छूता है: id, reads, writes, deposit और बोली। Body वह है जिसे सत्यापन उपभोग करता है: program, calldata, हस्ताक्षर। नमूना सत्यापन के अंतर्गत एक producer को केवल उन सर्टिफिकेटों की body चाहिए जिन्हें सत्यापित करने के लिए वह ड्रॉ किया गया है और बाक़ी सभी का head, और उसकी bandwidth कई परिमाण-क्रम घट जाती है। ब्लॉक पूरे exemplar के हैश के प्रति प्रतिबद्ध होता रहता है, और bodies चेन डेटा बनी रहती हैं, जिन्हें वे परोसते हैं जिन्होंने उन्हें सत्यापित किया और जो उन्हें संग्रहित करते हैं; जब हर नोड उन्हें नहीं रखता तब उनकी उपलब्धता की गारंटी कैसे होती है, यह वह प्रश्न है जिसका उत्तर उस Era को अस्तित्व में आने से पहले देना होगा [29]।

13. स्वीकृत जोखिम#

नियमों के वे परिणाम जिन्हें जैसे हैं वैसे ही स्वीकार किया गया है। हर एक सीमित है, या उस पक्ष पर पड़ता है जिसने उसे चुना; कोई भी किसी को किसी तीसरे पक्ष का नेटिव मूल्य लेने नहीं देता।

1. जिस कॉन्ट्रैक्ट का sequencer, admin और sequencer बदलने वाला कोड सब ग़ायब हो चुके हैं, उसे केवल forced path से छोड़ा जा सकता है: धीमा और अधिक महँगा, पर जीवित।
2. ख़ाली ब्लॉकों में दोनों base fees 7 पर आकर ठहरती हैं, जो उनके तल 1 से ऊपर है: 8 से नीचे नीचे की ओर का क़दम शून्य पर गोल हो जाता है। उस ठहराव बिंदु को हिलाने के लिए किसी Era सीमा पर पैरामीटर परिवर्तन चाहिए।
3. किसी गर्म कॉन्ट्रैक्ट पर लगभग एक ब्लॉक का सशुल्क fee उत्पीड़न (griefing): producer के अपने forced सर्टिफिकेट किसी उपयोगकर्ता के सर्टिफिकेट के आसपास रखे गए, उपयोगकर्ता के bounds से सीमित, और प्रति ब्लॉक एक forced सर्टिफिकेट जो sequencer से उसकी pipeline फिर बनवाता है।
4. एक open कॉन्ट्रैक्ट, जिसकी sequencer key शून्य है, केवल अपने कोड से सुरक्षित है, और उसके विरुद्ध किसी सर्टिफिकेट का लेखक अपने skips स्वयं चुकाता है: reads लेखक ने चुने।
5. किसी one-shot address पर उस सर्टिफिकेट के अलावा किसी और द्वारा credit किया गया ग़ैर-नेटिव एसेट, जो उस पते को जलाता है, जलाने से जम जाता है, क्योंकि जलाना केवल नेटिव balance और उन cells को हिलाता है जिन्हें वह सर्टिफिकेट लिखता है। किसी पते को जलाने से पहले उसके एसेट balances जाँचना wallet का नियम है, प्रोटोकॉल का नहीं।
6. जो सर्टिफिकेट केवल deltas हिलाता है वह fence को आगे नहीं बढ़ाता (§7); उससे पहले बना fill जो उसके द्वारा हिलाए गए cell को exact पढ़ता है, किसी बाद के ब्लॉक में skip होता है, और शुल्क sequencer से लिया जाता है। एक sequencer इससे यह करके बचता है कि वह ऐसा cell exact न पढ़े जिसे उसका कॉन्ट्रैक्ट किसी को भी delta से हिलाने देता है।
7. Forced-path निष्पादक का शेष उत्पीड़न: अनेक payers वाला एक हमलावर ऐसे open intents relay कर सकता है जिन्हें कोई सर्टिफिकेट नहीं ढो सकता, जैसे वह जिसके payer के पास भुगतान से कम राशि है। जो कॉल केवल revert होता है या अपने bounds तोड़ता है वह इनमें नहीं है: वह अपने विफल रूप में उतरता है और भुगतान करता है (§8)। हर न ढोया जा सकने वाला intent निष्पादक को एक build की क़ीमत देता है; फिर उस प्रति को निकालकर quarantine किया जाता है, और उसी payer पर किसी प्रतिस्थापन को सख़्ती से अधिक भुगतान करना होगा।
8. एक सह-हस्ताक्षरकर्ता कोई cell lock नहीं करता। उसके द्वारा हस्ताक्षरित एक संयुक्त fill उसकी pipeline में तब तक एक स्थान रखता है जब तक fill ढोया न जाए या उसकी विंडो बीत न जाए (§7)। समय पर न ढोया गया संयुक्त fill उन cells पर अन्य fills से टकरा सकता है; जो भी fold में दूसरे स्थान पर प्रवेश करता है वह skip होता है, और शुल्क उसके अपने depositor से लिया जाता है।
9. किसी open कॉन्ट्रैक्ट पर, जिस सर्टिफिकेट का deposit पता क्रम में पहले आता है वह exact reads की दौड़ जीतता है, और पते grind करना सस्ता है; जिस कॉन्ट्रैक्ट की exact स्टेट में होड़ है वह एक sequencer चुनता है, जिसकी pipeline क्रम तय करती है।
10. किसी open कॉन्ट्रैक्ट के exact पथ पर एक साधारण कॉल कॉन्ट्रैक्ट के sequencer cell को exact शून्य घोषित करता है। यदि सर्टिफिकेट के उतरने से पहले कॉन्ट्रैक्ट को कोई कुंजी मिल जाती है, तो read बासी है और कॉल skip होता है, शुल्क कॉल करने वाले से लिया जाता है; wallet ऐसा कॉल बनाने से पहले चेतावनी देता है।
11. Skip fee नियत है, इसलिए जब base fees ऊँची हों तो skip की लागत अनुप्रयोग से कम होती है; एक सर्टिफिकेट के कई रूप आज़माना सस्ता है, और हर नोड उनमें से हर एक को सत्यापित करता है।
12. उच्च throughput पर bandwidth और storage एक घोषित खुली समस्या हैं, हल की हुई नहीं: bodies चेन डेटा हैं, हर नोड हर बाइट ढोता है, एक मशीन कॉल वह कोड ढोता है जिसे वह चलाता है, और spent registry प्रति one-shot ख़र्च एक प्रविष्टि बढ़ती है। मार्ग §12 में है।
13. Proof of stake (§11) के अंतर्गत, चेन की सुरक्षा एक पारंपरिक proof of stake की सुरक्षा है: इसकी क़ीमत उतनी है जितनी ड्रॉ भार का बहुमत, delegations सहित, जुटाने की। Ramp अपनी समय-सीमा पर जो भी stake मौजूद हो उसके साथ शुरू होता है, और gate ही वह है जो switch को आपूर्ति का दसवाँ भाग रखने वाले सक्रिय stake के बिना पूरा होने से रोकता है; stake का दसवाँ भाग, अनुपस्थित रहकर, उसे रोक देता है। किसी pool की equivocation की क़ीमत केवल उसका अपना bond है, उसे जो भी delegate किया गया हो; delegators यह जानते हुए अपना pool चुनते हैं। तब से unbond हो चुकी कुंजियों से दीर्घ-परास (long-range) पुनर्लेखन केवल pinned checkpoints (§10) से रोका जाता है, जिन्हें जुड़ने वाला नोड अपनी रिलीज़ से स्वीकार करता है और चेन से व्युत्पन्न नहीं करता।

14. अनुरूपता#

नियम आर्किटेक्चर विनिर्देश हैं, golden vectors प्रोटोकॉल हैं, और जहाँ इनमें से कोई दो असहमत हों वहाँ अधिक सटीक जीतता है और असहमति एक बग है। प्रोटोकॉल एक प्रकाशित spec/ निर्देशिका में रहता है: पैरामीटर फ़ाइलें, chain-id ledger, pinned checkpoints, पहले से deploy की गई लाइब्रेरी की images और तीन vector संग्रह:

• fold vectors: (pre-state, block) → (post-state | invalid, outcomes, fees); एक invalid vector वह एकमात्र नियम दर्ज करता है जिसे वह तोड़ता है;
• derivation vectors: (program, declared reads and writes, deposit) → (reads, writes, artifact, parallel gas), या वह नियम जो मशीन तक पहुँचने से पहले सर्टिफिकेट को अस्वीकार करता है;
• difficulty vectors: (parameters, headers) → next target, किसी उम्मीदवार header पर निर्णय के साथ; proof of stake के अंतर्गत, (stake set, seed, slot) → drawn key।

Vectors उत्पन्न किए जाते हैं, कभी हाथ से संपादित नहीं। पुनर्जनन संदर्भ fold को चलाता है, परिणाम को उसके माध्यम से फिर से चलाता है, और फिर कमिट किए गए JSON को एक दूसरे, जानबूझकर सरल fold के माध्यम से फिर से चलाता है जो पहले के साथ कोई कोड साझा नहीं करता; जिस पुनर्जनन से दूसरा fold असहमत हो, वह विफल होता है। ऐसा पुनर्जनन जो किसी मौजूदा vector को बदलता है, एक consensus परिवर्तन है और उसकी समीक्षा उसी रूप में होती है। एक कार्यान्वयन तब अनुरूप है जब वह genesis id को पुनः उत्पन्न करता है और vectors पास करता है; तब वह एक peer है, fork नहीं।

15. v1.0 से संबंध#

यह पेपर v1.0 [0] का पूर्ण रूप से स्थान लेता है। जहाँ दोनों भिन्न हैं, वहाँ यह पेपर प्रोटोकॉल है और v1.0 को इसके साथ नहीं पढ़ा जाना चाहिए। मूल प्रतिपाद्य अपरिवर्तित है: स्व-प्रमाणित सर्टिफिकेट, एक fold जो कभी निष्पादन नहीं करता, टाइप्ड स्टेट एक्सेस, और दो fee मार्केट। नीचे के परिवर्तन डिज़ाइन को लागू करते समय पाए गए; हर एक ने consensus सतह और त्रुटियों के वर्ग हटाए।

16. निष्कर्ष#

Zycord लेनदेनों को निष्पादित करने के बजाय सर्टिफिकेटों को क्रमित करता है: validity किसी के भी द्वारा, कहीं भी, समांतर रूप से, केवल बाइट्स से जाँची जाती है; स्टेट एक fold द्वारा आगे बढ़ती है जो केवल तुलना करता और जोड़ता है; टकराव skip होते हैं, मूल्यांकित होते हैं और उनका शुल्क उस पक्ष से लिया जाता है जिसने उन्हें चुना; concurrency खोजी नहीं, घोषित की जाती है; एप्लिकेशन sequencers द्वारा मिलीसेकंडों में पुष्ट होते हैं, जिन पर liveness के लिए भरोसा किया जाता है और safety के लिए कभी नहीं; एक forced path जो हर कॉन्ट्रैक्ट को पहुँच में रखता है; और एक consensus जो, coin के वितरित हो जाने पर, अपनी गणना hashes के बजाय सत्यापन पर ख़र्च करता है। सत्यापन उस हार्डवेयर के साथ बाहर की ओर स्केल होता है जिसका स्वामी नेटवर्क नहीं है। प्रतिबद्धता अनुक्रमिक रहती है, और लगभग मुफ़्त।

सन्दर्भ#

[0] The Simstoshi. Zycord: A Peer-to-Peer Network of Self-Certifying State Transitions, v1.0. 2026. इस पेपर द्वारा प्रतिस्थापित।
[1] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.
[2] V. Buterin. Ethereum: A Next-Generation Smart Contract and Decentralized Application 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] J. Zahnentferner. Chimeric Ledgers: Translating and Unifying UTXO-based and Account-based Cryptocurrencies. IACR ePrint 2018/262.
[8] P. E. O'Neil. The Escrow Transactional Method. ACM TODS, 1986.
[9] M. Herlihy, E. Koskinen. Transactional Boosting: A Methodology for Highly-Concurrent Transactional Objects. PPoPP 2008.
[10] M. Shapiro et al. Conflict-free Replicated Data Types. SSS 2011.
[11] M. Corallo. BIP 152: Compact Block Relay. 2016.
[12] EIP-1559: Fee Market Change for the ETH 1.0 Chain. Ethereum Improvement Proposals, 2019.
[13] tevador et al. RandomX: Proof-of-Work Algorithm Optimized for General-Purpose CPUs. 2019.
[14] EIP-4844: Shard Blob Transactions. Ethereum Improvement Proposals, 2022.
[15] Monero: Dynamic Block Weight and Penalty. Monero Research Lab documentation.
[16] bitcoincashautist. CHIP-2023-04: Adaptive Blocksize Limit Algorithm for Bitcoin Cash. 2023.
[17] A. Kiayias, A. Russell, B. David, R. Oliynykov. Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol. CRYPTO 2017.
[18] B. David, P. Gaži, A. Kiayias, A. Russell. Ouroboros Praos: An Adaptively-Secure, Semi-Synchronous Proof-of-Stake Blockchain. EUROCRYPT 2018.
[19] Ethereum Foundation. Ethereum Consensus Specifications: The Beacon Chain (proposer slashings). 2020.
[20] L. Brünjes, A. Kiayias, E. Koutsoupias, A.-P. Stouka. Reward Sharing Schemes for Stake Pools. IEEE EuroS&P 2020.
[21] A. Yakovenko. Solana: A New Architecture for a High Performance Blockchain. 2017.
[22] Decred Documentation: Proof-of-Stake. docs.decred.org.
[23] Ethereum Foundation. The Merge. ethereum.org, 2022.
[24] M. M. T. Chakravarty, J. Chapman, K. MacKenzie, O. Melkonian, M. Peyton Jones, P. Wadler. The Extended UTXO Model. Financial Cryptography Workshops 2020.
[25] H. Kalodner, S. Goldfeder, X. Chen, S. M. Weinberg, E. W. Felten. Arbitrum: Scalable, Private Smart Contracts. USENIX Security 2018.
[26] V. Buterin. An Incomplete Guide to Rollups. 2021.
[27] A. Skidanov, I. Polosukhin. Nightshade: Near Protocol Sharding Design. 2019.
[28] G. Wood. Polkadot: Vision for a Heterogeneous Multi-Chain Framework. 2016.
[29] M. Al-Bassam, A. Sonnino, V. Buterin. Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities. 2018.
[30] D. Boneh, B. Bünz, B. Fisch. Batching Techniques for Accumulators with Applications to IOPs and Stateless Blockchains. CRYPTO 2019.
[31] S. Micali, M. Rabin, S. Vadhan. Verifiable Random Functions. FOCS 1999.

Zycord: लॉन्च, Eras और पैरामीटर#

The Simstoshi
2026 — v2.0
GPG: E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29

यह दस्तावेज़ Zycord: स्व-प्रमाणित स्टेट ट्रांज़िशन का एक पीयर-टू-पीयर नेटवर्क, v2.0 ("पेपर") का सहयोगी है। पेपर तंत्रों को परिभाषित करता है। यह दस्तावेज़ बताता है कि mainnet कैसे लॉन्च हुआ, coin कैसे जारी होता है, कौन सा Era क्या सक्रिय करता है, और हर पैरामीटर का मान। यह v1.0 पेपर के §13 और §14 का पूर्ण रूप से स्थान लेता है; जहाँ वे भिन्न हैं, वहाँ यह दस्तावेज़ निर्णायक है।

1. लॉन्च#

Mainnet genesis: 2026-10-07 00:00 UTC (1791331200), chain id 1।

• Proof of work के अंतर्गत हर 30 सेकंड में ब्लॉक; proof of stake पर switch से हर 5 सेकंड में (§6)। Proof of work: RandomX v2, CPU से माइन करने योग्य। Difficulty: 90-ब्लॉक विंडो पर LWMA।
• ब्लॉक 0 में कोई सर्टिफिकेट, कोई पता और कोई कुंजी नहीं है। ब्लॉक 0 से पहले कोई coin मौजूद नहीं है। Genesis प्रकाशित स्रोतों से पुनः उत्पन्न किया जा सकता है।
• कोई निवेशक दौर नहीं और कोई admin कुंजियाँ नहीं। कोई भी कोड पथ किसी कुंजी को रोकने, अपग्रेड करने, mint करने, सेंसर करने या पुनर्गठित करने नहीं देता।

लॉन्च प्रतिबद्धता। पैरामीटर सेट एक गुप्त लॉन्च संदेश के प्रति एक प्रतिबद्धता रखता है। ब्लॉक 1 को अपने header में उस प्रतिबद्धता को खोलना होगा, इसलिए केवल संदेश का धारक ही ब्लॉक 1 बना सकता है, और कोई और घोषित genesis से पहले शुरू होने वाली चेन पर work जमा नहीं कर सकता; निर्गमन ramp किसी भी शुरुआती बढ़त को बहुत कम मूल्य का बना देता है। ब्लॉक 2 से आगे, कोई भी माइनर बना सकता है।

Chain ids एक ledger में दर्ज हैं। Ledger, हर सक्रिय नेटवर्क की genesis id के साथ, हर binary में अंतर्निहित है और आरंभ पर जाँचा जाता है: नोड किसी सेवानिवृत्त id को अस्वीकार करता है, और ऐसे पैरामीटर सेट को भी जो किसी दर्ज id को भिन्न genesis दे देता। एक नोड उस work engine के अलावा किसी अन्य के साथ शुरू होने से इनकार करता है जिसे नेटवर्क घोषित करता है।

2. निर्गमन#

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

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

जहाँ E0 = प्रति ब्लॉक 21 ZCD, Q = 1054 और tail = प्रति ब्लॉक 0.33 ZCD, 30 सेकंड के proof-of-work अंतराल पर। दर लगभग हर दो वर्ष में आधी होती है। कोई floats नहीं और कोई तालिका नहीं। Genesis ब्लॉक कोई coinbase नहीं देता। Tail epoch 4,376 पर, लगभग वर्ष 12, शुरू होती है, जब 61,836,900.03 ZCD अनुसूचित हो चुके होते हैं: वे 62,744,838.47 जिनका योग अनुसूची देती है, लॉन्च ramp और genesis ब्लॉक को घटाकर। ये आँकड़े वही हैं जो recurrence उत्पन्न करती है; कोई नोड कभी closed form की गणना नहीं करता। एक ZCD 100,000,000 drops है।

धीमी शुरुआत। पहले 86,400 ब्लॉक (30 दिन) एक ramp हैं: ब्लॉक h E(30) · h / 86,400 देता है, उस epoch की दर जिसमें ramp समाप्त होता है, नीचे की ओर गोल, इसलिए इनाम लगभग शून्य से अनुसूची तक एक सीधी रेखा में बढ़ता है। Ramp जो रोकता है, लगभग 907,917 ZCD, वह कभी वापस नहीं दिया जाता।

अंतराल का परिवर्तन। Proof of stake पर switch से (§6), epoch 17,280 slots का होता है और प्रति ब्लॉक सब्सिडी E(n)/6 है, drops में नीचे की ओर गोल; recurrence नहीं बदलती। पूरे slots वाला एक दिन जो देता है वह दोनों अंतरालों में समान है: genesis वक्र पर प्रति ब्लॉक 21 ZCD प्रति 5-सेकंड ब्लॉक 3.5 के बराबर है, और 0.33 की tail 0.055 के बराबर। Tail उसी epoch, 4,376, पर शुरू होती है। गोलाई प्रति epoch एक ZCD के हज़ारवें भाग से कम रोकती है और वह कभी वापस नहीं दी जाती।

Tail उसे भुगतान करती है जो वर्तमान Era को सुरक्षित करता है, fee मार्केटों को बाध्य किए बिना। उसके विरुद्ध दोनों मार्केटों का base-fee burn और हर skip हुए सर्टिफिकेट का burn चलता है (पेपर §9), इसलिए शुद्ध निर्गमन tail घटा burn है और भार के अंतर्गत ऋणात्मक हो सकता है। आपूर्ति के अंश के रूप में tail शून्य की ओर प्रवृत्त होती है।

3. सब्सिडी विभाजन#

हर ब्लॉक सब्सिडी ब्लॉक 0 से consensus द्वारा 94 / 3 / 3 में विभाजित होती है। विभाजन केवल सब्सिडी पर लागू होता है, fees पर कभी नहीं, और हर ब्लॉक पर समान रूप से। Proof-of-stake ramp (§6) के दौरान producer का 94% स्वयं माइनर और ड्रॉ किए गए staker के बीच बँटता है, उस अंश के अनुसार जिस तक ramp पहुँचा है।

कोई premine नहीं है: विभाजन हर माइन किए गए ब्लॉक पर लागू एक नियम है, genesis पर कोई आवंटन नहीं। अपने तीन वर्षों में संस्थापक का अंश पूँछ-पूर्व आपूर्ति के 2% से कम होता है। जो producer नरम सीमा (पेपर §9) तोड़ता है, वह केवल अपने अंश से गँवाता है; treasury और संस्थापक के अंश बिना घटाई गई सब्सिडी से लिए जाते हैं।

4. Treasury#

Treasury cell प्रोटोकॉल पते का नेटिव balance है। कोई कुंजी उस तक हैश नहीं होती, कोई सर्टिफिकेट उससे debit नहीं कर सकता, और genesis कोई quorum नामित नहीं करता। यह ब्लॉक 1 से जमा होता है, और यह रिलीज़ कोई ख़र्च पथ बिल्कुल नहीं रखती। ख़र्च पथ एक अपग्रेड द्वारा परिभाषित होता है, ऊँचाई 259,200 (लगभग 5 जनवरी 2027) से पहले नहीं, जिसके हस्ताक्षरकर्ता समुदाय द्वारा चुने जाते हैं न कि संस्थापक द्वारा। तब तक cell एक सार्वजनिक पूर्णांक है जिसे कोई भी audit कर सकता है और कोई छू नहीं सकता।

5. संरक्षण: पहले तीन वर्ष (प्रस्ताव)#

स्थिति। यह अनुभाग समुदाय की समीक्षा के लिए एक दिशा है। इसमें कुछ भी तब तक consensus नियम नहीं है जब तक §4 का treasury अपग्रेड एक कुंजी सेट को pin न करे, और विवरण दिशा स्वीकार होने के बाद ही विनिर्दिष्ट किए जाते हैं।

Treasury को क्या मिलता है। वर्ष 1 में लगभग 533,000 ZCD, वर्ष 2 में 396,000 और वर्ष 3 में 280,000: कुल लगभग 1.21 मिलियन। वर्ष 4 से यह संस्थापक का 3% (§3) भी लेता है, उस वर्ष कुल लगभग 396,000 के लिए। इससे क्या ख़रीदा जा सकता है यह एक ऐसी क़ीमत पर निर्भर है जिसे कोई नहीं जानता, और एक पतला मार्केट बड़ी बिक्री नहीं झेल सकता, इसलिए योजना को निचले छोर पर काम करना होगा:

इसलिए नीचे की हर राशि treasury अंतर्वाह का एक अंश है, कभी डॉलर या ZCD में कोई आँकड़ा नहीं।

पाँच पद। पद अपने धारक से पहले परिभाषित किया जाता है। हर पद का एक सार्वजनिक charter है: उसके कर्तव्य, उसके deliverables, वह कैसे रिपोर्ट करता है और उसे क्या भुगतान मिलता है। कोई भी आवेदन कर सकता है। जो भी पद धारण करता है, वह एक अनुबंध की तरह charter की सेवा करता है।

निर्णय।

• एक ख़र्च के लिए 5 में से 3 चाहिए।
• किसी धारक को बदलने, कुंजियाँ घुमाने, आरक्षित निधि ख़र्च करने या किसी charter में संशोधन के लिए 5 में से 4 चाहिए, और यह प्रभावी होने से पहले 7 दिनों तक सार्वजनिक रहता है।
• कार्यकाल एक वर्ष का होता है और नवीकरणीय है। उम्मीदवारियाँ 30 दिनों तक सार्वजनिक रहती हैं। पहले पाँच धारक वह कुंजी सेट हैं जिसे नोड ऑपरेटरों द्वारा अपनाया गया अपग्रेड pin करता है; कोई बाद का hard fork उसे फिर से pin कर सकता है।

भुगतान भागीदारी है, वेतन नहीं। किसी पद का अंश लॉक होकर जमा होता है और हर छह महीने में जारी किया जाता है, एक प्रकाशित रिपोर्ट और अन्य 4 धारकों में से 3 के मतों के आधार पर। कोई धारक अपने स्वयं के भुगतान के जारी होने पर मत नहीं देता। जो जारी नहीं होता वह आरक्षित निधि में लौटता है। पद का भुगतान charters द्वारा निश्चित है और किसी ख़र्च मत से तय नहीं होता। प्रति पद एक सीमा, जो जारी होने की तिथि पर मार्केट क़ीमत पर मापी जाती है, किसी भी अतिरेक को आरक्षित निधि में भेजती है।

बजट, अंतर्वाह के अंशों के रूप में।

अवसंरचना का पहला दावा है: नोड, seeds, explorer और build सर्वरों की लागत आज लगभग US$ 500 प्रति माह है। प्रतिपूर्ति उसी दिन के बाज़ार मूल्य पर परिवर्तित होती है जिस दिन भुगतान होता है। यह अंश उस लागत को वर्ष 1 में लगभग US$ 0.06 प्रति ZCD, वर्ष 2 में US$ 0.08 और वर्ष 3 में US$ 0.11 पर ढकता है; उससे नीचे, कमी बिना ब्याज के आगे ले जाई जाती है और तब चुकाई जाती है जब अंश अनुमति दे।

संस्थापक। सब्सिडी का संस्थापक का 3% (§3) लॉन्च तक और लॉन्च पर किए गए काम का पुरस्कार है। यह मुख्य-डेवलपर पद से अलग है, जिसे चल रहे काम के लिए किसी भी अन्य पद की तरह भुगतान मिलता है। संस्थापक पाँच में से एक कुंजी रखता है और उस पद के भुगतान के जारी होने पर मत नहीं देता।

Consensus क्या लागू करता है। अपग्रेड लागू होने पर: 5 में से 3 वाला ख़र्च और अपने विलम्ब के साथ 5 में से 4 वाला rotation। इस अनुभाग में बाक़ी सब कुछ एक मानदंड है। किसी मानदंड को लागू करने वाली बात यह है कि हर ख़र्च एक साधारण सर्टिफिकेट है, सार्वजनिक और केवल चेन से गिना जा सकने वाला।

खुले प्रश्न। प्रति पद सीमा। वह क़ानूनी रूप जिसके अंतर्गत सार्वजनिक प्रतिनिधि हस्ताक्षर करता है। क्या मशीन सक्रिय होने के बाद छह-महीने का lock मानक लाइब्रेरी के एक escrow कॉन्ट्रैक्ट द्वारा लागू किया जाएगा।

6. Eras#

Eras सार्वजनिक रिलीज़ों में compile किए गए ऊँचाई स्थिरांक हैं। किसी gate से नीचे का ब्लॉक जो ऐसा program ढोता है जिसे वह gate सक्षम करता है, invalid है, और वह ऊँचाई जाँच ही Eras को अलग करने वाली एकमात्र चीज़ है, सिवाय Era 2 के ramp और switch के, जो ऊँचाई-सीमाओं के भीतर स्टेट द्वारा ट्रिगर होते हैं। एक नया Era नियम और रिकॉर्ड प्रकार जोड़ सकता है; वह कभी यह नहीं बदलता कि कोई मौजूदा ब्लॉक अपनी सक्रियण ऊँचाई से नीचे क्या अर्थ रखता है।

Era 2 और S हर एक hard fork द्वारा अपनी अलग रिलीज़ के रूप में आते हैं, एक विनिर्देश, एक प्रतिकूल (adversarial) devnet और समीक्षा के साथ। Era 2 ऊँचाई के आधार पर bonding खोलता है, एक समय-सीमा के साथ stake के आधार पर अपना ramp शुरू करता है, और ramp पूरा होने पर switch करता है: switch सबसे पहले epoch 303 (महीना 10) पर हो सकता है, और शुरुआत पर समय-सीमा गारंटी देती है कि ramp महीना 9 के अंत तक चालू हो। 10% की सीमा के लिए, stake अपनी delegations के साथ सक्रिय stake है और आपूर्ति जारी किया गया coin है, दोनों epoch के आरंभ पर। Gate switch को epoch 363 से आगे रोक सकता है; जो वह नहीं कर सकता वह है उसे शुरू होने से रोकना।

Stake। न्यूनतम bond 1,000 ZCD है, और एक stake bond किए जाने के एक epoch बाद भाग लेता है। जो bond केवल delegate करता है उसका न्यूनतम छोटा है, जिसे उस Era की रिलीज़ तय करती है, और वह कभी delegator की अभिरक्षा नहीं छोड़ता। न्यूनतम ZCD में है, डॉलर में नहीं, क्योंकि कोई नियम कोई मूल्य नहीं पढ़ सकता; ब्लॉक सीमा बढ़ने के साथ Era सीमाओं पर इसे संशोधित किया जाता है।

Era 0 जानबूझकर बहुत छोटा है और Era 1 को उतने तक घटाया गया है जितना डिज़ाइन को चाहिए: admin कुंजियों के बिना कोई pause बटन नहीं है, इसलिए consensus की हर पंक्ति एक ऐसी पंक्ति है जो बिना उपचार के नेटवर्क को मार सकती है। अगम्य consensus कोड अ-लेखा-परीक्षणीय consensus कोड है और उसे भेजा नहीं जाता। जो Era अपनी जटिलता के योग्य सिद्ध नहीं होता, उसे कभी ट्रिगर नहीं किया जाता।

संक्रमण सँभाला जा सकता है क्योंकि fold इस बात से निरपेक्ष है कि क्रम कौन देता है: Era 2 यह बदलता है कि header पर किसका हस्ताक्षर है।

Era 1 gate। Gate ब्लॉक उस Era के compile किए गए स्थिरांकों को प्रोटोकॉल cells में लिखता है, इसलिए state root तब से उनके प्रति प्रतिबद्ध रहता है। Gate के बाद के पहले 240 ब्लॉकों में, SETSEQ चलाने वाले सर्टिफिकेट को gate से कम से कम 240 ब्लॉक आगे का TTL रखना होगा और उसके सीमा में आने की प्रतीक्षा करनी होगी।

Era 2 और समय मापने वाली ऊँचाइयाँ। Switch के बाद, ऊँचाई छह गुना तेज़ी से बढ़ती है। हर genesis स्थिरांक जो वास्तव में एक अवधि है (संस्थापक के अंश का अंत, coinbase maturity, अधिकतम TTL, intent विंडो, undo गहराई, median-time विंडो, directory प्रविष्टि का जीवनकाल) Era 2 द्वारा उस इकाई में पढ़ा जाता है जिसे वह मापता है: ऊँचाई 3,153,600 2,880 के 1,095 epochs है, और यह Era संस्थापक का अंश epoch 1,095 पर समाप्त करता है। Genesis पैरामीटर तालिका नहीं बदलती, क्योंकि consensus root हर पैरामीटर से होकर गुज़रता है और किसी एक को हिलाने से हर सक्रिय नेटवर्क की genesis id हिल जाती; इस Era के स्थिरांक Era 1 की तरह compile किए जाते हैं।

7. पैरामीटर#

पैरामीटर सेट genesis पर स्थिर कर दिया जाता है, compile के समय हर binary में अंतर्निहित होता है, और केवल hard fork द्वारा परिवर्तनीय है। उसका consensus root हर हस्ताक्षर में प्रवेश करता है। zcd params किसी build के संकलित मान छापता है; zcd genesis नेटवर्क, chain id, पैरामीटर हैश, genesis id और state root छापता है।

Era 1 के स्थिरांक compile किए जाते हैं, पैरामीटर नहीं हैं, क्योंकि consensus root हर पैरामीटर से होकर गुज़रता है और एक जोड़ने से हर सक्रिय नेटवर्क की genesis id हिल जाती।

Era 2 के स्थिरांक इसी कारण compile किए जाते हैं।