Tadge Dryja

सोचिए, हर कप कॉफ़ी के भुगतान की दुनिया भर के नोड, यानी बिटकॉइन के नियम जाँचने वाले कंप्यूटरों, को अलग-अलग जाँच करनी पड़े। अपना नोड चलाने के लिए लगातार अधिक शक्तिशाली कंप्यूटर माँगे बिना भुगतान कैसे बढ़ाएँ? Joseph Poon और Thaddeus Dryja ने भुगतान चैनलों के नेटवर्क में इसका रास्ता खोजा। यहाँ दिया whitepaper, यानी डिज़ाइन समझाने वाला दस्तावेज़, 14 जनवरी 2016 का है और उस पर DRAFT 0.5.9.2 लिखा है। यह ऐतिहासिक प्रस्ताव विचार की शुरुआत समझाता है; आज के प्रोग्रामों के सटीक नियम उनके अपने दस्तावेज़ों में पढ़ने चाहिए। [1]

भुगतान चैनल को पहले जमा किए गए बिटकॉइन के बँटवारे पर लगातार बदलते समझौते की तरह समझ सकते हैं। हर भुगतान से दोनों पक्षों का हिस्सा बदलता है। वे इन बदलावों पर हस्ताक्षर करते हैं, लेकिन हर अपडेट को ब्लॉकचेन, यानी साझा लेनदेन इतिहास, पर प्रकाशित नहीं करते। सहयोग समाप्त होने पर Bitcoin लेनदेन के ज़रिए रकम का बँटवारा लागू किया जा सकता है। इस तरह Lightning कई अपडेट ब्लॉकचेन से बाहर रखता है, जबकि अंतिम निपटारा बिटकॉइन के नियमों पर ही निर्भर रहता है। [1]

पुराने समझौते में किसी व्यक्ति का हिस्सा अधिक दिख सकता है, जबकि वह उसका कुछ भाग खर्च कर चुका हो। प्रस्ताव के निरस्तीकरण मॉडल में, रद्द किए गए पुराने स्टेट को प्रकाशित करने पर दूसरे पक्ष को दंड वाला लेनदेन भेजकर जवाब देने का अवसर मिलता है। लेकिन यह तय समय-सीमा में करना पड़ता है। इसलिए सहभागी या उसका नियुक्त निगरानीकर्ता ब्लॉकचेन पर नज़र रखता है। व्यावहारिक बात यह है कि क्रिप्टोग्राफी होने भर से बिना निगरानी हमेशा ऑफ़लाइन रहना सुरक्षित नहीं हो जाता। भरोसेमंद निगरानी धन की सुरक्षा का हिस्सा है। [1]

बिटकॉइन अपने आप नहीं जानता कि तय तारीख को किसी मुद्रा की विनिमय दर क्या थी। Discreet Log Contracts, या DLC, ऐसे अनुबंधों को संबोधित करते हैं जिनका निपटारा इस जानकारी पर निर्भर है। दो सहभागी शर्तें और संभावित भुगतान पहले तैयार करते हैं। चुना हुआ oracle, यानी बाहरी डेटा स्रोत, बाद में परिणाम की घोषणा पर हस्ताक्षर करता है। सहभागी उससे संबंधित निपटारा करते हैं। इस मॉडल में oracle उनका धन नहीं रखता और उसे यह जानना भी ज़रूरी नहीं कि उसकी घोषणाएँ कौन इस्तेमाल करता है। वह जानकारी देता है, किसी और का वॉलेट नहीं चलाता। [2]

डिजिटल हस्ताक्षर यह जाँचने में मदद करता है कि संदेश किसने जारी किया और उसमें बदलाव तो नहीं हुआ। लेकिन वह जानकारी की सच्चाई साबित नहीं करता। Oracle गलत दर बता सकता है या कुछ भी प्रकाशित नहीं कर सकता। ऐसी चुप्पी के लिए Dryja पहले से तैयार रिफंड लेनदेन का वर्णन करते हैं, जिसे सहमत समय-सीमा के बाद प्रकाशित किया जा सकता है। पैसा अपने आप नहीं लौटता: यह व्यवस्था अनुबंध में पहले से होनी चाहिए और किसी को इसका इस्तेमाल करना होगा। विश्वसनीय स्रोत चुनना और उसके बंद होने की योजना बनाना इसलिए महत्वपूर्ण रहता है। [2]

Dryja ने यह भी अध्ययन किया कि भुगतान जाँचने के लिए नोड को कितना डेटा रखना चाहिए। UTXO अभी तक खर्च न हुए लेनदेन आउटपुट हैं: अलग-अलग रकम और उन्हें खर्च करने की शर्तें। Utreexo जाँच करने वाले नोड को इनके समूह का प्रतिनिधित्व एक छोटे क्रिप्टोग्राफिक सार, जिसे accumulator कहते हैं, से करने देता है। भुगतान के साथ प्रमाण आता है कि इस्तेमाल किया जा रहा आउटपुट इसी समूह में है। इससे वर्तमान स्थिति के संग्रहित प्रतिनिधित्व का आकार घटता है। नियमों की जाँच समाप्त नहीं होती और बिटकॉइन का पूरा इतिहास एक छोटी फ़ाइल में नहीं बदलता। [4]

Utreexo के प्रमाण भी जाँचकर्ता तक पहुँचने चाहिए। इसलिए छोटा संग्रहित स्टेट अधिक डेटा ट्रांसफ़र माँग सकता है। शोध का सार 2019 की शुरुआत तक की ब्लॉकचेन डाउनलोड करने के एक सिमुलेशन का वर्णन करता है। उपयोगी डेटा के अस्थायी संग्रह, यानी cache, के लिए 500 MB देने पर प्रमाणों ने डाउनलोड मात्रा लगभग 25% बढ़ाई। यहाँ 500 MB पूरे नोड की कुल मेमोरी नहीं है। यह खास प्रयोग का परिणाम है, आज की आवश्यकताओं की गारंटी नहीं। बचत का आकलन करते समय डिस्क, मेमोरी और डेटा ट्रांसफ़र को साथ देखना चाहिए। [3]

MIT DCI में प्रकाशित अपने संस्मरण में Dryja ने MIT में सहज शुरुआत का वर्णन किया: कंप्यूटर लेकर आए, बिटकॉइन पर बातचीत की और छात्रों की मदद की। फिर निदेशक Neha Narula ने पूछा कि क्या वे वहाँ काम करना चाहेंगे। बाद में दोनों ने साथ पढ़ाया भी। उसी विदाई लेख में उन्होंने बिटकॉइन और Lightning पर काम जारी रखने के लिए Lightspark जाने की घोषणा की। यह विवरण करियर के एक दौर का रिकॉर्ड है, वर्तमान नौकरी की पुष्टि नहीं। किसी एक पदनाम से अधिक, उनके प्रकाशन, कोड और समझाए गए विचार उनके योगदान को बताते हैं। [5]