सुनो। मैं मृणाल वाधवा, ओकाम में सीटीओ हूं। ओकाम के शुरुआती दिनों में, हम एक सी लाइब्रेरी विकसित कर रहे थे। यह कहानी है कि क्यों, कई महीनों में, हमने C की हज़ारों पंक्तियों को छोड़कर रस्ट में फिर से लिखने का निर्णय लिया।
शुरू करने से पहले, मैं इस सप्ताह इन्फ्लक्सडेटा के सीटीओ पॉल डिक्स के साथ एक रिकॉर्डेड वेबिनार में था, जहां हम दोनों ने इन्फ्लक्सडीबी और रस्ट में ओकम के पुनर्लेखन पर चर्चा की। दो ओपन सोर्स प्रोजेक्ट्स ने फिर से लिखना क्यों चुना, हमने रस्ट को अपनी नई भाषा के रूप में क्यों चुना, इस दौरान हमने जो सबक सीखे, और भी बहुत कुछ। रिकॉर्डिंग जरूर जांचें. यह एक ज्ञानवर्धक चर्चा थी.
ओकैम डेवलपर्स को ऐसे एप्लिकेशन बनाने में सक्षम बनाता है जो डेटा-इन-मोशन पर भरोसा कर सकते हैं। हम आपको किसी भी वातावरण में चल रहे किसी भी एप्लिकेशन में एंड-टू-एंड एन्क्रिप्टेड और पारस्परिक रूप से प्रमाणित संचार जोड़ने के लिए सरल उपकरण देते हैं। आपके ऐप्स को निजी नेटवर्क पर, कई क्लाउड के बीच, काफ्का में संदेश स्ट्रीम के माध्यम से - किसी भी मल्टी-हॉप, मल्टी-प्रोटोकॉल टोपोलॉजी पर डेटा अखंडता, प्रामाणिकता और गोपनीयता की एंड-टू-एंड गारंटी मिलती है। सभी संचार शुरू से अंत तक प्रमाणित और निजी हो जाते हैं।
हम कठिन भागों को भी स्केल करना बहुत आसान बनाते हैं - बूटस्ट्रैप विश्वास संबंध, सुरक्षित रूप से कुंजियाँ प्रबंधित करना, अल्पकालिक क्रेडेंशियल्स को घुमाना/निरस्त करना, विशेषता-आधारित प्राधिकरण नीतियों को लागू करना, आदि। अंतिम परिणाम यह है - आप उन ऐप्स का निर्माण कर सकते हैं जिनके पास ग्रैनुलर नियंत्रण है प्रत्येक विश्वास और पहुंच संबंधी निर्णय - ऐसे ऐप्स जो निजी और डिज़ाइन द्वारा सुरक्षित हैं।
2019 में, हमने सी में यह सब बनाना शुरू किया। हम चाहते थे कि ओकैम हर जगह चले - सीमित किनारे वाले उपकरणों से लेकर शक्तिशाली क्लाउड सर्वर तक। हम यह भी चाहते थे कि ओकाम किसी भी प्रकार के एप्लिकेशन में प्रयोग योग्य हो - चाहे एप्लिकेशन किसी भी भाषा में बनाया गया हो।
इसने C को एक स्पष्ट उम्मीदवार बना दिया। इसे 99% कंप्यूटरों के लिए संकलित किया जा सकता है और लगभग हर जगह चलाया जा सकता है (एक बार जब आप यह समझ लें कि सभी लक्ष्य-विशिष्ट टूलचेन से कैसे निपटना है)। और अन्य सभी लोकप्रिय भाषाएँ किसी मूल फ़ंक्शन इंटरफ़ेस के माध्यम से सी लाइब्रेरीज़ को कॉल कर सकती हैं - इसलिए हम बाद में हर दूसरी भाषा के लिए भाषा मुहावरेदार रैपर प्रदान कर सकते हैं: टाइपस्क्रिप्ट, पायथन, एलिक्सिर, जावा, आदि।
विचार यह था कि हम अपने संचार-केंद्रित प्रोटोकॉल के मूल को किसी भी हार्डवेयर-विशिष्ट व्यवहार से अलग रखेंगे और जिस हार्डवेयर का हम समर्थन करना चाहते हैं उसके लिए प्लग करने योग्य एडाप्टर रखेंगे। उदाहरण के लिए, विभिन्न एचएसएम में गुप्त कुंजी संग्रहीत करने के लिए एडाप्टर, विभिन्न परिवहन प्रोटोकॉल के लिए एडाप्टर आदि होंगे।
हमारी योजना अपने मूल को सी लाइब्रेरी के रूप में लागू करने की थी। फिर हम इस सी लाइब्रेरी को अन्य भाषाओं के रैपर के साथ लपेटेंगे और प्लग करने योग्य हार्डवेयर एडेप्टर की मदद से इसे हर जगह चलाएंगे।
लेकिन, हम सादगी की भी गहरी परवाह करते हैं - यह हमारे नाम में है। हम चाहते हैं कि ओकाम उपयोग में सरल, निर्माण में सरल और रखरखाव में सरल हो।
ओकैम के मूल में ओकैम सिक्योर चैनल्स और ओकैम रूटिंग जैसे क्रिप्टोग्राफ़िक और संदेश-आधारित प्रोटोकॉल का एक स्तरित ढेर है। ये एसिंक्रोनस, मल्टी-स्टेप, स्टेटफुल संचार प्रोटोकॉल हैं और हम एप्लिकेशन डेवलपर्स से इन प्रोटोकॉल के सभी विवरणों को अलग करना चाहते थे। हमने एंड-टू-एंड प्रमाणित और एन्क्रिप्टेड सुरक्षित चैनल बनाने के लिए उपयोगकर्ता अनुभव को एक एकल-लाइन फ़ंक्शन कॉल के रूप में कल्पना की।
क्रिप्टोग्राफी-संबंधित कोड में भी बहुत सारे फ़ुटगन होते हैं, एक छोटी सी गलती, और आपका सिस्टम असुरक्षित हो जाता है। इसलिए सादगी हमारे लिए सिर्फ एक सौंदर्यवादी आदर्श नहीं है, हमें लगता है कि यह सुनिश्चित करना एक महत्वपूर्ण आवश्यकता है कि हम सुरक्षित सिस्टम बनाने के लिए हर किसी को सशक्त बना सकें। इसमें शामिल प्रत्येक प्रोटोकॉल की बारीकियों को जानना आवश्यक नहीं होना चाहिए। हम इन फ़ुटगन को छुपाना चाहते थे और डेवलपर इंटरफ़ेस प्रदान करना चाहते थे जो सही ढंग से उपयोग करने में आसान हो और इस तरह से उपयोग करना असंभव/कठिन हो जो आपके एप्लिकेशन को पैर में गोली मार दे।
यहीं पर सी की भारी कमी थी।
सी में सुरक्षित और सरल इंटरफेस को उजागर करने के हमारे प्रयास सफल नहीं रहे। प्रत्येक पुनरावृत्ति में, हमने पाया कि एप्लिकेशन डेवलपर्स को प्रोटोकॉल स्थिति और राज्य संक्रमण के बारे में बहुत अधिक विवरण जानने की आवश्यकता होगी।
लगभग उसी समय मैंने एलिक्सिर में ओकैम रूटिंग पर एक ओकैम सिक्योर चैनल बनाने का एक प्रोटोटाइप लिखा था।
एलिक्सिर प्रोग्राम BEAM, एर्लांग वर्चुअल मशीन पर चलते हैं। BEAM एर्लैंग प्रक्रियाएं प्रदान करता है। एरलांग प्रक्रियाएं हल्के स्टेटफुल समवर्ती अभिनेता हैं। चूंकि अभिनेता आंतरिक स्थिति को बनाए रखते हुए समवर्ती रूप से चला सकते हैं, इसलिए स्टेटफुल प्रोटोकॉल ओकम ट्रांसपोर्ट्स + ओकम रूटिंग + ओकम सिक्योर चैनल्स के समवर्ती स्टैक को चलाना आसान हो गया।
मैं सभी स्टेटफुल परतों को छिपाने और एक सरल एक-पंक्ति फ़ंक्शन बनाने में सक्षम था जिसे कोई व्यक्ति विभिन्न मल्टी-हॉप, मल्टी-प्रोटोकॉल मार्गों पर एंड-टू-एंड एन्क्रिप्टेड सुरक्षित चैनल बनाने के लिए कॉल कर सकता है।
{:ok, channel} = Ockam.SecureChannel.create(route, vault, keypair)
एक एप्लिकेशन डेवलपर इस सरल फ़ंक्शन को लागू करेगा और कई समवर्ती अभिनेता स्टेटफुल प्रोटोकॉल की अंतर्निहित परतों को चलाएंगे। चैनल स्थापित होने पर या कोई त्रुटि होने पर फ़ंक्शन वापस आ जाएगा। यह वही है जो हम अपने इंटरफ़ेस में चाहते थे।
लेकिन एलिक्सिर सी की तरह नहीं है। यह छोटे/बाधित कंप्यूटरों पर उतनी अच्छी तरह से नहीं चलता है और यह भाषा-विशिष्ट मुहावरेदार आवरणों में लपेटे जाने के लिए एक अच्छा विकल्प नहीं है।
इस बिंदु पर, हम जानते थे कि हम हल्के अभिनेताओं को लागू करना चाहते थे लेकिन हम यह भी जानते थे कि सी इतना आसान नहीं होगा। यह तब हुआ जब मैंने रस्ट में खुदाई शुरू की और बहुत जल्द ही कुछ चीजें सामने आईं जिन्होंने रस्ट को बहुत आकर्षक बना दिया:
रस्ट लाइब्रेरीज़ एक इंटरफ़ेस निर्यात कर सकती हैं जो सी के कॉलिंग कन्वेंशन के साथ संगत है। इसका मतलब यह है कि कोई भी भाषा या रनटाइम जो स्थिर या गतिशील रूप से सी लाइब्रेरी में फ़ंक्शन को लिंक और कॉल कर सकता है, वह रस्ट लाइब्रेरी में भी फ़ंक्शन को लिंक और कॉल कर सकता है - ठीक उसी तरह। चूँकि अधिकांश भाषाएँ C में मूल कार्यों का समर्थन करती हैं, वे पहले से ही रस्ट में भी मूल कार्यों का समर्थन करती हैं। इसने हमारी मुख्य लाइब्रेरी के चारों ओर भाषा-विशिष्ट रैपर रखने की हमारी आवश्यकता के परिप्रेक्ष्य से रस्ट को सी के बराबर बना दिया।
रस्ट एलएलवीएम का उपयोग करके संकलित करता है जिसका अर्थ है कि यह बहुत बड़ी संख्या में कंप्यूटरों को लक्षित कर सकता है। यह सेट संभवतः उतना बड़ा नहीं है जितना कि सी जीसीसी और विभिन्न मालिकाना जीसीसी फोर्क्स के साथ लक्ष्य कर सकता है लेकिन फिर भी यह एक बहुत बड़ा उपसमूह है और रस्ट को जीसीसी के साथ संकलित करने के लिए काम चल रहा है। नए एलएलवीएम लक्ष्यों के बढ़ते समर्थन और रस्ट में संभावित जीसीसी समर्थन के साथ, यह हर जगह चलने में सक्षम होने की हमारी आवश्यकता के परिप्रेक्ष्य से एक अच्छा दांव लग रहा था।
रस्ट की प्रकार प्रणाली हमें अपरिवर्तनीयों को संकलन-समय त्रुटियों में बदलने की अनुमति देती है। यह संभावित गलतियों के समूह को कम कर देता है जिन्हें विकास के समय पकड़ना आसान बनाकर उत्पादन में भेजा जा सकता है। हमारी टीम और हमारी रस्ट लाइब्रेरी के उपयोगकर्ता के व्यवहार संबंधी बग या सुरक्षा कमजोरियों को उत्पादन में भेजने की संभावना कम हो जाती है।
रस्ट की मेमोरी सुरक्षा विशेषताएं उपयोग के बाद फ़्रीज़, डबल फ़्रीज़, ओवरफ़्लो, आउट-ऑफ़-बाउंड एक्सेस, डेटा रेस और कई अन्य सामान्य गलतियों की संभावना को खत्म कर देती हैं, जो बड़े सी में 60-70% उच्च-गंभीर कमजोरियों का कारण बनती हैं। या C++ कोडबेस। रस्ट कचरा संग्रहकर्ता का उपयोग करके रनटाइम पर मेमोरी को सुरक्षित रूप से प्रबंधित करने की प्रदर्शन लागत के बिना संकलन समय पर यह सुरक्षा प्रदान करता है। इससे रस्ट को कोड लिखने का एक गंभीर लाभ मिलता है जिसे अत्यधिक प्रदर्शन करने वाला, प्रतिबंधित वातावरण में चलाने और अत्यधिक सुरक्षित होने की आवश्यकता होती है।
अंतिम टुकड़ा जिसने मुझे आश्वस्त किया कि रस्ट ओकाम के लिए बिल्कुल उपयुक्त है, वह async/await
था। हमने पहले ही पहचान लिया था कि ओकम के प्रोटोकॉल का एक सरल और सुरक्षित इंटरफ़ेस बनाने के लिए हमें हल्के अभिनेताओं की आवश्यकता है। async/await
का मतलब है कि अभिनेताओं को बनाने के लिए बहुत सारी मेहनत टोकियो और async-std जैसी परियोजनाओं में पहले ही की जा चुकी है। हम इस आधार पर ओकाम के अभिनेता कार्यान्वयन का निर्माण कर सकते हैं।
एक और महत्वपूर्ण पहलू जो सामने आया वह यह था कि जंग में async/await
जावास्क्रिप्ट जैसी अन्य भाषाओं async/await
से एक महत्वपूर्ण अंतर है। जावास्क्रिप्ट में एक ब्राउज़र इंजन या नोडज एसिंक फ़ंक्शन चलाने का तरीका चुनता है। लेकिन रस्ट में आप अपनी पसंद का एक तंत्र प्लगइन कर सकते हैं। इन्हें एसिंक रनटाइम कहा जाता है - टोकियो ऐसे रनटाइम का एक लोकप्रिय उदाहरण है जो अत्यधिक स्केलेबल सिस्टम के लिए अनुकूलित है। लेकिन हमें हमेशा टोकियो का उपयोग करने की ज़रूरत नहीं है, हम इसके बजाय छोटे एम्बेडेड डिवाइस या माइक्रोकंट्रोलर के लिए अनुकूलित एसिंक रनटाइम चुन सकते हैं।
इसका मतलब यह था कि ओकाम का अभिनेता कार्यान्वयन, जिसे हमने बाद में ओकाम वर्कर्स कहा, अगर हम इसे रस्ट के async/await
पर आधारित करते हैं, तो यह हमारे उपयोगकर्ताओं के लिए बिल्कुल वही इंटरफ़ेस प्रस्तुत कर सकता है, चाहे वह कहीं भी चल रहा हो - बड़े कंप्यूटर या छोटे कंप्यूटर। हमारे सभी प्रोटोकॉल इंटरफ़ेस जो ओकम वर्कर्स के शीर्ष पर होंगे, वे भी बिल्कुल वही सरल इंटरफ़ेस प्रस्तुत कर सकते हैं - चाहे वे कहीं भी चल रहे हों।
इस बिंदु पर हम आश्वस्त थे कि हमें ओकम को रस्ट में फिर से लिखना चाहिए। वेबिनार वार्तालाप में, जिसका मैंने पहले उल्लेख किया था, पॉल डिक्स और मैंने चर्चा की थी कि प्रत्येक प्रोजेक्ट द्वारा रस्ट पर स्विच करने का निर्णय लेने के बाद ओकैम और इन्फ्लक्सडीबी में हमारी टीमों के लिए परिवर्तन कैसा दिखेगा। हमने चर्चा की कि कैसे इन्फ्लक्सडीबी गो से रस्ट में चला गया और ओकाम सी से रस्ट में कैसे चला गया। यदि आप रुचि रखते हैं, तो हमारी यात्रा के उस हिस्से में रिकॉर्डिंग सुनें।
कई पुनरावृत्तियों के बाद, कोई भी अब एक साधारण फ़ंक्शन कॉल के साथ एंड-टू-एंड एन्क्रिप्टेड और पारस्परिक रूप से प्रमाणित सुरक्षित चैनल बनाने के लिए रस्ट में ओकम क्रेट का उपयोग कर सकता है।
यहां वह एक पंक्ति है, जिसकी कल्पना हमने तब की थी जब हमने शुरुआत की थी:
let channel = node.create_secure_channel(&identity, route, options).await?;
यह मनमाने मल्टी-हॉप, मल्टी-प्रोटोकॉल मार्गों पर एक प्रमाणित और एन्क्रिप्टेड चैनल बनाता है जो निजी नेटवर्क और क्लाउड तक फैल सकता है। हम इस सरल और सुरक्षित फ़ंक्शन कॉल के पीछे सभी अंतर्निहित जटिलताओं और फ़ुट गन को छिपाने में सक्षम हैं। चाहे आप इसका उपयोग कैसे भी करें, कोड वही रहता है - स्केलेबल सर्वर या छोटे माइक्रोकंट्रोलर पर।
अधिक जानने के लिए, GitHub पर Ockam को देखें या Ockam Rust लाइब्रेरी और Ockam Command के चरण-दर-चरण वॉक-थ्रू आज़माएँ।
यदि आप किसी ऐसे प्रोजेक्ट का हिस्सा रहे हैं जिसे रस्ट में दोबारा लिखा गया था, तो आइए हमारे डिसॉर्डर सर्वर पर अपनी टीम की कहानी हमारे साथ साझा करें। हम रस्ट और एलिक्सिर दोनों भूमिकाओं के लिए भी भर्ती कर रहे हैं, आइए बिल्डरों की हमारी टीम में शामिल हों - हम डिज़ाइन द्वारा सॉफ़्टवेयर को अधिक सुरक्षित और निजी बनाने की खोज में हैं।