412 / 736GARZIK

Jeff Garzik

Bitcoin उपकरण डेवलपर और BIP लेखक

Jeff Garzik ने माइनिंग और बिटकॉइन ऐप्लिकेशन के लिए उपकरण बनाए तथा नेटवर्क संचार और ब्लॉक आकार में बदलाव सुझाए। उनका काम उपयोगी प्रोग्राम, तकनीकी प्रस्ताव और नेटवर्क के प्रतिभागियों द्वारा सचमुच अपनाए गए नियम के बीच का फर्क समझाता है।

Jeff Garzik डेवलपर हैं, जिन्हें jgarzik खाते से जाना जाता है। उन्होंने बिटकॉइन सॉफ़्टवेयर और BIP पर काम किया। BIP ऐसे दस्तावेज हैं जो किसी खास बदलाव या प्रक्रिया का वर्णन करते हैं। उनका योगदान बताता है कि बिटकॉइन कैसे विकसित होता है: लेखक कोड लिख सकता है और नियम सुझा सकता है, लेकिन पूरे नेटवर्क को उसे अपनाने का आदेश नहीं दे सकता।

GitHub पर Jeff Garzik, jgarzik नाम इस्तेमाल करते हैं। उनके काम को अलग-अलग रिपॉज़िटरी में देखा जा सकता है, यानी सार्वजनिक जगहों पर जहाँ कोड और उसके बदलावों का इतिहास रखा जाता है। यह किसी एक व्यक्ति को “बिटकॉइन चलाने वाला” कह देने से ज्यादा उपयोगी है। किसी प्रोग्राम के लिए यह समझना जरूरी है कि वह क्या करता है और कौन-सा संस्करण सामने है; किसी प्रस्ताव के लिए यह कि वह क्या बदलना चाहता था। डेवलपर की प्रोफ़ाइल अपने आप तय नहीं करती कि दूसरे लोग सॉफ़्टवेयर का कौन-सा संस्करण चलाएँगे। [1]

Garzik के cpuminer का परिचय देने वाला README इसे CPU, यानी कंप्यूटर के प्रोसेसर, से Bitcoin माइनिंग करने का प्रोग्राम बताता है। कई थ्रेड इस्तेमाल करने से गणना का काम एक साथ चलने वाले अलग-अलग कार्यप्रवाहों में बाँटा जा सकता है। Litecoin और Bitcoin के लिए बना pooler/cpuminer साफ बताता है कि वह इसी प्रोग्राम से निकला है। मौजूद कोड लेकर उसे अलग विकसित करना परियोजना का fork कहलाता है। इससे अपने आप बिटकॉइन नेटवर्क नहीं बँटता। बाद में जोड़ी गई सुविधाएँ जरूरी नहीं कि Garzik के मूल प्रोग्राम में भी रही हों। [2] [3]

दूसरा उदाहरण Picocoin है। इसमें C भाषा की libccoin लाइब्रेरी है, जिसके कामों का उपयोग डेवलपर बिटकॉइन ऐप्लिकेशन बनाने में कर सकते हैं। लेकिन README संबंधित HD वॉलेट और brd नोड को WIP, यानी अभी निर्माणाधीन, बताता है। HD वॉलेट एक साझा आधार से कई संबंधित कुंजियाँ बनाता है; नोड बिटकॉइन नेटवर्क से संवाद करने के लिए होता है। रिपॉज़िटरी 15 फ़रवरी 2024 को आर्काइव कर दी गई। इतिहास समझने के लिए यह उपयोगी है, लेकिन कोड उपलब्ध होने भर से यह साबित नहीं होता कि उत्पाद पूरा है, उसका रखरखाव हो रहा है और वह अपनी बचत रखने के लिए सुरक्षित है। [4]

मान लीजिए एक नोड जानना चाहता है कि उससे जुड़ा दूसरा नोड कौन-से अपुष्ट लेनदेन जानता है। Garzik का BIP 35 यही काम बताता है: mempool संदेश सूची माँगता है, inv उत्तर में लेनदेन की पहचान, उनके हैश, आते हैं और getdata से बाद में असली डेटा माँगा जा सकता है। Mempool पुष्टि से पहले लेनदेन का स्थानीय “प्रतीक्षालय” है, पूरी दुनिया की एक साझा सूची नहीं। Bitcoin Core के दस्तावेजों में getrawmempool कमांड भी किसी खास नोड की सामग्री लौटाता है। वहाँ लेनदेन मिलना यह नहीं बताता कि ब्लॉक में उसकी पुष्टि हो गई है। [5] [8]

ब्लॉक आकार से लेनदेन की जगह और उन्हें भेजने तथा जाँचने के लिए जरूरी संसाधन प्रभावित होते हैं। BIP 100 में Garzik, Tom Harding और Dagur Valberg Johannsson ने माइनरों द्वारा ब्लॉक में दर्ज वोटों के अनुसार सीमा बदलने का प्रस्ताव रखा। हर 2016 ब्लॉक पर दोबारा गणना होती, ब्लॉकों में 75% समर्थन जरूरी होता और हर बदलाव की मात्रा सीमित रहती। यानी वोट लोगों की संख्या के आधार पर नहीं गिने जाते। रजिस्टर प्रस्ताव को Closed, यानी बंद, बताता है; उसका वर्णन पूरे बिटकॉइन नेटवर्क द्वारा अपनाए जाने का प्रमाण नहीं है। [6]

एक सामान्य नोड को लें जो अभी भी मूल 1 MB सीमा जाँचता है। बड़ा ब्लॉक मिलने पर वह उसे अस्वीकार करेगा, भले ही उसे बनाने वाला माइनर ऊँची सीमा का समर्थन करे। BIP 100 ठीक इसी विभाजन की चेतावनी देता है। ब्लॉक में लिखा वोट डेटा है जिसे नया सॉफ़्टवेयर समझ सकता है; वह पुराने प्रोग्राम को दोबारा लिखने का आदेश नहीं है। पुराने नियमों द्वारा अस्वीकार किए जाने वाले ब्लॉक स्वीकार करने का बदलाव Hard Fork है। यहाँ fork का अर्थ GitHub पर केवल अलग परियोजना बनाने से अलग है। [6]

Garzik के BIP 102 ने अलग तरीका सुझाया: सीमा एक बार बढ़ाकर 2 MB करना। सक्रिय करने के लिए तय समय की शर्त और पिछले 1000 ब्लॉक में 95% समर्थन के संकेत, दोनों जरूरी होते। शर्तें पूरी होने से पुराने सत्यापन प्रोग्राम अपने आप नहीं बदलते; वे बड़े ब्लॉक अस्वीकार करते रहते। यह प्रस्ताव भी Closed है। यह सुझाए गए बदलाव का दस्तावेज है, आज बिटकॉइन पर लागू ब्लॉक आकार के नियमों की व्याख्या नहीं। [7]

हर BIP में सामग्री और स्थिति दोनों पढ़नी चाहिए। BIP 35, Peer Services स्तर पर Deployed, यानी लागू, दर्ज है। यह स्तर नोडों के बीच सेवाओं और संचार से जुड़ा है। BIP 100 और BIP 102, Consensus (hard fork) स्तर पर Closed हैं, क्योंकि वे बताते हैं कि नोड किन ब्लॉकों को वैध मानें। एक ही लेखक दोनों क्षेत्रों में काम कर सकता है और नतीजे अलग हो सकते हैं। नेटवर्क संदेश सफलतापूर्वक लागू होने का मतलब यह नहीं कि उस लेखक के सभी नियम-संबंधी प्रस्ताव भी लागू हो गए। [5] [6] [7]

पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Cynthia Lummis, Mike Hearn, ब्लॉक आकार युद्ध. इस प्रविष्टि का उल्लेख यहाँ भी है Mike Hearn.

DOC · 001Garzik — public developer profileदस्तावेज़ DOC · 002Garzik — reference cpuminer READMEदस्तावेज़ DOC · 003Pooler — cpuminer ancestryदस्तावेज़ DOC · 004Garzik — Picocoin archive and READMEदस्तावेज़ DOC · 005BIP 35 — mempool messageदस्तावेज़ DOC · 006BIP 100 — dynamic block-size proposalदस्तावेज़ DOC · 007BIP 102 — two-megabyte proposalदस्तावेज़ DOC · 008Bitcoin Core 29.0 — local mempool RPCदस्तावेज़
समीक्षा की गई: स्रोत पहले · यह निवेश सलाह नहीं है