रेडिक्स इंजन: “प्रतिष्ठा के लिए एक बेहतर मॉडल”

मेरे में पिछला लेख , मैंने बताया कि कैसे रेडिक्स इंजन ने सुई के मूववीएम में कुछ खामियों को दूर किया। संक्षेप में:

• सुई का MoveVM बहुत निम्न-स्तरीय और सामान्य है, जिससे DeFi प्रोग्रामिंग वातावरण बोझिल हो जाता है।
• रेडिक्स इंजन उच्च-स्तरीय और परिसंपत्ति + व्यावसायिक तर्क-उन्मुख है, जो डेवलपर्स को निम्न-स्तरीय विवरणों के बजाय DeFi तर्क पर ध्यान केंद्रित करने की अनुमति देता है।

सुई का मूववीएम मूल का अनुसरण करता है एथेरियम दर्शन एक "साफ, सरल, सुंदर" प्रोटोकॉल, जो सब कुछ एप्लीकेशन लेयर को सौंपता है। यह डेवलपर्स को किसी भी डोमेन को एक्सप्लोर करने की स्वतंत्रता देता है, जिसमें उस समय अज्ञात डोमेन भी शामिल हैं।

हालाँकि, एक प्रोटोकॉल जो बहुत सरल और असंरचित है, महत्वपूर्ण समझौते करता है। उदाहरण के लिए, प्राधिकरण जैसी सामान्य सिस्टम सुविधाओं के लिए एप्लिकेशन स्पेस में जटिल कार्यान्वयन की आवश्यकता होगी, मानक इंटरफ़ेस अधिक विखंडित हो सकते हैं, और प्रदर्शन अनुकूलन अधिक कठिन हो जाता है।

दूसरी ओर, रेडिक्स इंजन को गैर-सामान्य, सिस्टम-व्यापी तर्क को मुख्य तकनीकी लक्ष्य के रूप में क्रियान्वित करने के लिए डिज़ाइन किया गया है, क्योंकि यह हमें निम्नलिखित कार्य करने की अनुमति देता है:

• सिस्टम-वाइड मानकों/कार्यान्वयन को लागू करें । एक विचारशील मानक स्टैक में विकास/रखरखाव/टूलिंग को आसान बनाता है क्योंकि API खंडित नहीं होते हैं (उदाहरण के लिए, ERC-20 बनाम ERC-721 बनाम ERC-404), और व्यवहार को समझने के लिए बाइटकोड व्याख्या की आवश्यकता नहीं होती है (कोई और ERC-20 रग पुल नहीं)। यह डेवलपर्स और अंतिम उपयोगकर्ताओं को एक सुरक्षित, अधिक सुसंगत DeFi अनुभव देता है।
• हार्डवेयर के करीब तर्क को निष्पादित करें। चूंकि सिस्टम तर्क को शुद्धता के लिए किसी इंटरप्रेटर द्वारा चलाने की आवश्यकता नहीं होती है, इसलिए उस तर्क का निष्पादन यथासंभव हार्डवेयर के करीब चलाया जा सकता है।
• निष्पादन को समानांतर बनाएँ। कुछ वस्तुओं के व्यवहार का प्रत्यक्ष ज्ञान होने से, निष्पादन से पहले स्थैतिक विश्लेषण निर्णय लेना आसान हो जाता है, जिससे समानांतर निष्पादन संभव हो जाता है।

विटालिक ने हाल ही में इस विचार को " मंदिर में स्थापन ”, या प्रोटोकॉल-लागू तर्क के लाभों को प्राप्त करने के लिए अमूर्तता से चुनिंदा रूप से अलग होने का विचार। अपनी छवियों में से एक को चुराते हुए, वह समस्या को अमूर्तता बनाम प्रतिष्ठापन के बीच एक समझौते के रूप में प्रस्तुत करता है:

अमूर्तता (यानी, भविष्य/विविध उपयोगकर्ता ज़रूरतों) का समर्थन करते हुए प्रदर्शन/सुरक्षा/प्रयोज्यता (यानी, प्रतिष्ठापन) को बनाए रखने का यह संतुलन वास्तव में एक बहुत पुरानी कंप्यूटर विज्ञान समस्या है। ऑपरेटिंग सिस्टम का डिज़ाइन विशेष रूप से पिछले दशकों से इसी तरह की समस्या को हल करने की कोशिश कर रहा है: हम एक तेज़, सुरक्षित, प्रयोग करने योग्य सिस्टम को बनाए रखते हुए अमूर्त अनुप्रयोगों की एक श्रृंखला का समर्थन कैसे करते हैं?

इस लेख में, मैं यह बताऊंगा कि कैसे रेडिक्स इंजन ऑपरेटिंग सिस्टम मॉडल का उपयोग करके सभी प्रकार के "एनशाइनमेंट" में सक्षम फ्रेमवर्क का निर्माण करता है, बिना प्रोटोकॉल जटिलता के भार या लचीलेपन की हानि के, जिससे विटालिक डरते हैं।

आइए वर्तमान उद्योग मानक, एथेरियम वर्चुअल मशीन ("ईवीएम") को देखकर शुरुआत करें।

वीएम के रूप में ईवीएम

ईवीएम इतना बुनियादी है कि इसे निम्नलिखित ऑपकोड के साथ एक वर्चुअल मशीन ("वीएम") के रूप में मॉडल किया जा सकता है:

• ट्यूरिंग-पूर्ण ऑपोड सेट
• अन्य स्मार्ट अनुबंधों के लिए कॉल के लिए ऑपकोड
• वर्तमान स्मार्ट अनुबंध के स्वामित्व वाले स्थायी भंडारण को पढ़ने/लिखने के लिए ऑपकोड

ईवीएम बाइटकोड में संकलित स्मार्ट अनुबंधों को फिर ऐसे वीएम के शीर्ष पर निष्पादित किया जा सकता है।

इस मॉडल में, किसी भी प्रकार के "एनशाइनमेंट" के लिए EVM या VM हार्डवेयर में बदलाव की आवश्यकता होती है। उदाहरण के लिए, BLS सिग्नेचर सपोर्ट को एनशाइन करने के लिए एक नया प्रीकंपाइल जोड़ना होगा। ईआईपी-2938 नए ऑपकोड को जोड़ने की आवश्यकता होगी। जो कुछ भी पहले से ही मौजूद है, उसका विस्तार करने से अनिवार्य रूप से एक बड़ा, अधिक जटिल वीएम प्राप्त होता है और प्रोटोकॉल डिज़ाइनर को विटालिक द्वारा वर्णित एक या दूसरे निर्णय लेने के लिए मजबूर होना पड़ता है।

इस मॉडल के साथ सामान्य समस्या यह है कि अमूर्तन/संस्थापन द्विभाजन सॉफ्टवेयर/हार्डवेयर द्विभाजन के साथ बहुत अधिक जुड़ा हुआ है। यानी, प्रोटोकॉल में किसी भी तर्क को शामिल करने से उसे VM में एम्बेड करने के लिए बाध्य होना पड़ता है। "संस्थापित सॉफ़्टवेयर" या सिस्टम का हिस्सा होने वाले सॉफ़्टवेयर को व्यक्त करने का कोई तरीका नहीं है।

ऑपरेटिंग सिस्टम ने "सिस्टम सॉफ्टवेयर" की अवधारणा के साथ इस द्वंद्व को हल किया। आइए इस पर करीब से नज़र डालें।

ऑपरेटिंग सिस्टम मॉडल

ऑपरेटिंग सिस्टम का एक मुख्य लक्ष्य सॉफ़्टवेयर/हार्डवेयर द्विभाजन को प्रबंधित करना है - या, अधिक विशेष रूप से, एप्लिकेशन/हार्डवेयर द्विभाजन को। किसी भी ऑपरेटिंग सिस्टम का मुख्य भाग कर्नेल है, जो उपयोगकर्ता स्थान अनुप्रयोगों और हार्डवेयर तक उनकी पहुँच को प्रबंधित करने वाला सॉफ़्टवेयर है। कर्नेल मॉड्यूल और ड्राइवर सिस्टम सॉफ़्टवेयर के अतिरिक्त भाग हैं जो समर्थित हार्डवेयर के सेट का विस्तार करते हैं या कर्नेल कार्यक्षमता को बढ़ाते हैं।

\"एनशाइनमेंट" के नज़रिए से, कर्नेल और उसके मॉड्यूल सिस्टम के एनशाइन किए गए हिस्से हैं, लेकिन उनमें सॉफ़्टवेयर की तरह लचीलापन होता है। कर्नेल मॉड्यूल, वर्चुअल मशीन ("VMs") और यूज़र-स्पेस सिस्टम प्रक्रियाएँ और भी ज़्यादा "सॉफ्ट" हैं, क्योंकि इन्हें कर्नेल से ही अलग किया जाता है।

इस मॉडल में, अनुप्रयोगों और हार्डवेयर के बीच अप्रत्यक्षता की परत सॉफ्टवेयर/हार्डवेयर द्वंद्व को अमूर्तता/प्रतिष्ठा द्वंद्व से अलग करने की अनुमति देती है। "सिस्टम सॉफ्टवेयर" हार्डवेयर पर अत्यधिक बोझ डाले बिना प्रतिष्ठा की अनुमति देता है।

ऑपरेटिंग सिस्टम के रूप में रेडिक्स इंजन

इस ऑपरेटिंग सिस्टम मॉडल को प्रेरणा के रूप में उपयोग करते हुए, रेडिक्स इंजन में कई परतें शामिल हैं, जिनमें से प्रत्येक में एक विशिष्ट जिम्मेदारी और अमूर्तता है, जो सिस्टम मॉड्यूलरिटी और प्लगैबिलिटी की अनुमति देता है।

ऐसा मॉड्यूलर डिज़ाइन सिस्टम लॉजिक को लागू करने की अनुमति देता है, साथ ही निम्नलिखित की भी अनुमति देता है:

• जिस परत में यह है, उसके अलगाव गुणों को विरासत में लें । उदाहरण के लिए, एक एनश्राइन पैकेज, हालांकि एनश्राइन किया गया है, मनमाने ढंग से स्थिति तक नहीं पहुंच सकता है लेकिन उसे एप्लिकेशन लेयर सीमाओं का पालन करना होगा। यह उपयोगकर्ता-स्थान ड्राइवरों या माइक्रोकर्नेल डिज़ाइन में देखी जाने वाली एक समान प्रकार की सुरक्षा है। यानी, सिस्टम के प्रत्येक भाग को अलग करके जोखिम को कम किया जाता है ताकि सिस्टम में कोई भी अपडेट (एनश्राइनमेंट) पूरे सिस्टम को जोखिम में न डाले।
• उस परत की सुविधाओं तक पहुँच प्राप्त करें जिसमें यह है। उदाहरण के लिए, एक स्थापित पैकेज सिस्टम द्वारा प्रदान की गई प्रमाणीकरण और/या अपग्रेडेबिलिटी सुविधाओं को प्राप्त कर सकता है।
• शासन को पृथक करें। यह मॉड्यूलर डिज़ाइन प्रत्येक मॉड्यूल में समानांतर और अलग-अलग गति से नवाचार की अनुमति देता है।

आइये अब हम इनमें से प्रत्येक स्तर पर नजर डालें और देखें कि उनकी जिम्मेदारियां क्या हैं।

अनुप्रयोग परत

एप्लीकेशन लेयर उच्च-स्तरीय तर्क को परिभाषित करने के लिए जिम्मेदार है। इस तर्क का वर्णन करने वाले बाइटकोड को अन्य स्थिर जानकारी के साथ एक निष्पादन योग्य प्रारूप में बंडल किया जाता है जिसे पैकेज कहा जाता है। पैकेज तब लेज़र पर संग्रहीत होते हैं और निष्पादन के लिए उपलब्ध होते हैं।

स्क्रिप्टो में लिखे गए एप्लिकेशन, जो कि रस्ट-आधारित भाषा है जिसे हमने DeFi विकास के लिए बनाया है, इस परत में रहते हैं। स्क्रिप्टो प्रोग्राम WASM प्रोग्राम में संकलित होते हैं, जिसमें फ़ंक्शन निर्यात के एक सेट तक पहुँच होती है जो प्रोग्राम को सिस्टम/कर्नेल सेवाओं तक पहुँचने की अनुमति देता है। यह सिस्टम कॉल एपीआई लिनक्स के समान है सिस्टम कॉल , जो साझा I/O तक पहुंच प्रदान करते हैं।

वीएम परत

अगली परत पर चलते हुए, VM परत एप्लीकेशन परत के लिए कंप्यूटिंग वातावरण प्रदान करने के लिए जिम्मेदार होती है। इसमें ट्यूरिंग-पूर्ण VM के साथ-साथ सिस्टम परत तक पहुँचने के लिए इंटरफ़ेस भी शामिल होता है।

रेडिक्स इंजन वर्तमान में दो VM का समर्थन करता है: एक स्क्रिप्टो WASM VM जिसका उपयोग स्क्रिप्टो अनुप्रयोगों को निष्पादित करने के लिए किया जाता है, तथा एक मूल VM जो होस्ट के वातावरण में संकलित मूल पैकेजों को निष्पादित करता है।

यदि हम विशेष रूप से स्क्रिप्टो WASM VM पर नज़र डालें, तो यह इस प्रकार दिखता है:

यह मूलतः ईवीएम मॉडल जैसा ही लग सकता है, लेकिन इसमें दो महत्वपूर्ण अंतर हैं:

• स्टोरेज तक सीधी पहुँच को हटाना। प्रत्येक स्मार्ट कॉन्ट्रैक्ट के केवल अपने स्वामित्व वाले स्टोरेज तक पहुँचने में सक्षम होने के बजाय, कोई भी स्टेट रीड/राइट सिस्टम कॉल के माध्यम से किया जाता है। अप्रत्यक्षता की यह परत सिस्टम में कई दिलचस्प चीजों को लागू करने की अनुमति देती है, जैसे कि अनुप्रयोगों में स्टेट शेयरिंग, स्टेट वर्चुअलाइजेशन, आदि। अप्रत्यक्षता की यह परत द्वारा प्रदान की गई अप्रत्यक्षता के समान है आभासी मेमोरी या लिनक्स का फ़ाइल डिस्क्रिप्टर .

  
  

• सिस्टम कॉल का जोड़ । सिस्टम कॉल वह तंत्र है जिसके द्वारा एप्लिकेशन लेयर सिस्टम लेयर की सेवाओं तक पहुँच सकता है, जैसे कि अन्य एप्लिकेशन को इनवोकेशन करना या किसी ऑब्जेक्ट में डेटा लिखना। ये सिस्टम कॉल वास्तविक CPU में सॉफ़्टवेयर इंटरप्ट निर्देशों के समान हैं (उदाहरण के लिए, int यहाँ x86 में अनुदेश)।

सिस्टम परत

सिस्टम लेयर सिस्टम मॉड्यूल या प्लग करने योग्य सॉफ़्टवेयर के एक सेट को बनाए रखने के लिए ज़िम्मेदार है जो सिस्टम की कार्यक्षमता को बढ़ा सकता है। ये लिनक्स के समान हैं कर्नेल मॉड्यूल .

प्रत्येक सिस्टम कॉल पर, सिस्टम लेयर द्वारा कर्नेल लेयर को नियंत्रण सौंपे जाने से पहले प्रत्येक सिस्टम मॉड्यूल को कॉल किया जाता है। कॉल किए जाने पर, प्रत्येक सिस्टम मॉड्यूल कुछ विशेष स्थिति को अपडेट कर सकता है (जैसे, खर्च की गई अपडेट फीस) या लेनदेन को समाप्त करने के लिए पैनिक हो सकता है (जैसे, यदि टाइप चेकर विफल हो जाता है)।

यह पैटर्न सिस्टम को अनुप्रयोग और कर्नेल दोनों परतों से अलग रहते हुए प्राधिकरण, रॉयल्टी या प्रकार जांच जैसी कार्यक्षमता को क्रियान्वित करने की अनुमति देता है।

कर्नेल परत

कर्नेल परत रेडिक्स इंजन की दो मुख्य कार्यात्मकताओं के लिए जिम्मेदार है: स्टोरेज एक्सेस और अनुप्रयोगों के बीच संचार। यह कुछ हद तक पारंपरिक ऑपरेटिंग सिस्टम की डिस्क और नेटवर्क एक्सेस की जिम्मेदारी के समान है।

रेडिक्स इंजन के लिए, इसमें निम्नलिखित निम्न-स्तरीय प्रबंधन शामिल हैं:

• जाँच करें कि किसी भी आह्वान या डेटा लेखन पर मूव/बॉरो सिमेंटिक्स बनाए रखा जाता है। एकल-स्वामी नियम और उधार नियम कर्नेल द्वारा लागू किए जाते हैं। इनमें से किसी भी नियम के विफल होने पर, लेनदेन में गड़बड़ी होगी।
• क्षणिक बनाम स्थायी ऑब्जेक्ट्स को प्रबंधित करें। कोई ऑब्जेक्ट किसी भी समय वैश्विक स्थान में हो सकता है या कॉल फ़्रेम के स्वामित्व में हो सकता है। कर्नेल रनटाइम के दौरान इन ऑब्जेक्ट्स के लिए सही पॉइंटर्स बनाए रखता है क्योंकि इन ऑब्जेक्ट्स के संदर्भ पास किए जाते हैं।
• लेनदेन स्थिति अद्यतनों का प्रबंधन करें। कर्नेल लेनदेन के दौरान हुए स्थिति अद्यतनों का ट्रैक रखता है और जिन्हें बाद में लेनदेन के अंत में डेटाबेस में प्रतिबद्ध किया जाएगा।

एनश्राइन्ड सॉफ्टवेयर

ये परतें DLT प्रोटोकॉल में एनश्राइनमेंट से कैसे संबंधित हैं? ऑपरेटिंग सिस्टम में कर्नेल परत के समान, रेडिक्स इंजन की ये मध्य परतें सॉफ़्टवेयर/हार्डवेयर डिचोटोमी से अमूर्तता/एनश्राइनमेंट डिचोटोमी को अलग करने और "एनश्राइन्ड सॉफ़्टवेयर" की धारणा बनाने के लिए आवश्यक अप्रत्यक्षता प्रदान करती हैं।

एनश्राइन्ड सॉफ्टवेयर में सॉफ्टवेयर के लचीलेपन और सुरक्षा गुण होते हैं, साथ ही सिस्टम-व्यापी तर्क को लागू करने की क्षमता भी बनी रहती है।

आइए कुछ ऐसे एनशाइनमेंट उदाहरणों पर नजर डालें जो वर्तमान में रेडिक्स नेटवर्क पर चल रहे हैं और देखें कि उनका क्रियान्वयन किस प्रकार किया जाता है।

संरक्षित संसाधन

रेडिक्स डेफी/वेब3 प्लेटफ़ॉर्म का मुख्य अंतर यह विचार है कि एक संसाधन (यानी, संपत्ति) एक मौलिक आदिम है जिसे व्यावसायिक तर्क से अलग से समझा जाना चाहिए। इस अवधारणा को सुनिश्चित करने से सभी dApps, वॉलेट और टूलिंग को एक आम समझ मिलती है कि किसी संपत्ति का इंटरफ़ेस और व्यवहार कैसा दिखता है, जिससे संयोजन बहुत आसान हो जाता है।

यद्यपि संसाधन प्रणाली के सबसे अंतर्निहित भागों में से एक हैं, लेकिन इसके कार्यान्वयन के लिए केवल दो मॉड्यूलर सॉफ्टवेयर की आवश्यकता होती है:

• एक मूल पैकेज जो संसाधन ऑब्जेक्ट्स जैसे बकेट, वॉल्ट और प्रूफ के तर्क को संभालता है

• एक सिस्टम मॉड्यूल जो इन वस्तुओं के जीवनकाल अपरिवर्तनीयता को लागू करता है (जैसे संसाधनों की गतिशीलता और दहनशीलता)

  
  

यह तथ्य कि रेडिक्स इंजन सिस्टम/कर्नेल से पृथक रहते हुए भी एक मानकीकृत, चल संसाधन की गहन अवधारणा को व्यक्त कर सकता है, एक मॉड्यूलर सिस्टम सॉफ्टवेयर फ्रेमवर्क की शक्ति को दर्शाता है।

प्रतिष्ठित प्राधिकरण और रॉयल्टी

रेडिक्स इंजन इस तर्क को व्यावसायिक तर्क से अलग करके और इन्हें सिस्टम सुविधाओं के रूप में लागू करके प्राधिकरण और रॉयल्टी को मानकीकृत करता है। यह उपयोगकर्ताओं और डेवलपर्स को किसी भी फ़ंक्शन को ऑन-लेजर तक पहुँचने के लिए आवश्यकताओं को समझने का एक अंतर्निहित सामान्य तरीका प्रदान करता है।

सिस्टम लॉजिक से बिजनेस लॉजिक को अलग करने की मॉड्यूलरिटी, सुविधाजनक विकास/डिबगिंग विकल्पों की भी अनुमति देती है, जैसे कि सामान्य प्रमाणीकरण जांच के बिना लेनदेन का पूर्वावलोकन करने की क्षमता (क्या आप कहीं 10 मिलियन USDC भेजने के परिणाम का अनुकरण करना चाहते हैं? प्राधिकरण अक्षम होने पर, आपका पूर्वावलोकन लेनदेन खनन कर सकता है!)।

प्रमाणीकरण और रॉयल्टी सुनिश्चित करने के लिए चार मॉड्यूलर सॉफ्टवेयर की आवश्यकता होती है:

• प्रमाणीकरण और रॉयल्टी मूल पैकेज जो अनुप्रयोग परत को किसी भी ऑब्जेक्ट के प्रमाणीकरण/रॉयल्टी तक पहुंचने की अनुमति देते हैं (उदाहरण के लिए, किसी विधि तक पहुंचने के लिए प्रमाणीकरण नियम को पुनः प्राप्त करना या रॉयल्टी का दावा करना)।

• ऑथ और रॉयल्टी सिस्टम मॉड्यूल को ऑब्जेक्ट विधि कॉल से पहले कॉल किया जाता है ताकि यह सत्यापित किया जा सके कि कॉल करने वाले के पास कॉल करने और रॉयल्टी एकत्र करने के लिए पर्याप्त प्राधिकरण है या नहीं।

  
  

  
  

प्रतिष्ठित लेनदेन

किसी भी सिस्टम के उपयोग योग्य होने के लिए उपयोगकर्ता और सिस्टम के बीच सही इंटरफ़ेस का होना बहुत ज़रूरी है। उपयोग योग्य होने के लिए, इंटरफ़ेस को उपयोग में आसानी और शक्ति/लचीलेपन के बीच सही संतुलन बनाना होगा।

ऑपरेटिंग सिस्टम की दुनिया में, सबसे आम इंटरफ़ेस टर्मिनल है, जो एक यूजर स्पेस प्रक्रिया है जो उपयोगकर्ता को विभिन्न सिस्टम कॉल करने और बनाने के लिए एक कमांड लाइन टूल प्रदान करती है।

डीएलटी दुनिया में, यह इंटरफ़ेस ही लेनदेन है। लेनदेन के लिए उद्योग मानक एकल निम्न-स्तरीय, सामान्य इनवोकेशन कॉल का उपयोग करना है। दुर्भाग्य से, यह इतना सरल है कि यह समझना मुश्किल हो जाता है कि सिस्टम के साथ बातचीत करते समय कोई वास्तव में क्या कर रहा है।

दूसरी ओर, रेडिक्स इंजन पारंपरिक ओएस पैटर्न का उपयोग करता है और एक अनुप्रयोग भाषा (बैश जैसी टर्मिनल स्क्रिप्टिंग भाषा के समान) को एक ही लेनदेन में सिस्टम कॉल करने और बनाने के लिए उपयोग करता है।

क्योंकि लेनदेन का प्रवेश बिंदु अनुप्रयोग परत में संचालित होता है, इसलिए भाषा दुभाषिया को लेनदेन प्रोसेसर मूल पैकेज जोड़कर कार्यान्वित किया जाता है।

प्रतिष्ठापित बीएलएस

BLS सिग्नेचर एक महत्वपूर्ण क्रिप्टो प्रिमिटिव हैं क्योंकि वे थ्रेशोल्ड सिग्नेचर की संभावना की अनुमति देते हैं। दुर्भाग्य से, WASM में इस तरह के लॉजिक को चलाने से अधिकतम लागत इकाई का उपयोग जल्दी हो जाता है। हाल ही में "एनेमोन" अपडेट में, हमने इसे मूल रूप से निष्पादित करके BLS को सुनिश्चित किया और WASM की तुलना में प्रदर्शन में 500 गुना वृद्धि पाई।

क्योंकि BLS तर्क स्टेटलेस है, इसे आसानी से स्क्रिप्टो WASM VM में अतिरिक्त प्रीकंपाइल के रूप में जोड़ा जा सकता है।

निष्कर्ष

किसी भी DLT प्रोटोकॉल के लिए क्या सुनिश्चित करना है और क्या नहीं, यह महत्वपूर्ण है। दुर्भाग्य से, उद्योग का मौजूदा VM मॉडल हर सुनिश्चित करने के निर्णय को एक उच्च-दांव वाला निर्णय बनाता है।

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

मूल रूप से, ऑपरेटिंग सिस्टम का मतलब एक छोटा सा सॉफ्टवेयर था जिसे कई अनुप्रयोगों के लिए साझा संसाधनों का प्रबंधन करने के लिए डिज़ाइन किया गया था। जैसे-जैसे उपयोगकर्ताओं की मांग बेहतर, तेज़, अधिक सुरक्षित प्लेटफ़ॉर्म के लिए बढ़ती गई, इसने सॉफ़्टवेयर के बड़े और बड़े सूट के साथ अधिक से अधिक ज़िम्मेदारी ली है।

DeFi भी इससे अलग नहीं होगा। जैसे-जैसे तेज़, ज़्यादा सुरक्षित और ज़्यादा इस्तेमाल करने लायक DeFi प्लैटफ़ॉर्म की मांग बढ़ेगी, एनशाइनमेंट में भी इज़ाफ़ा होगा। रेडिक्स इंजन को इसी बात को ध्यान में रखकर डिज़ाइन किया गया है और यह भविष्य में एनशाइनमेंट के विस्तार के लिए ज़रूरी स्केलेबल और सुरक्षित ढांचा प्रदान करता है।