देव मल्टीवर्स के लिए अगली पीढ़ी के FHE टूलचेन: TFHE हमें वहां कैसे ले जा रहा है

परिचय

एफएचई खेल को बदल रहा है, और हम सभी को इसमें खेलने के लिए आमंत्रित किया गया है।

अगर आपको इस बारे में कोई जानकारी नहीं है कि मैं किस बारे में बात कर रहा हूँ, तो इसका मतलब है कि आप हाल ही में किसी उलझन में हैं। FHE.org के कुछ व्यापक संसाधनों को ब्राउज़ करें और वापस आएँ।

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

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

जहाँ तक मेरा मानना है, यह स्पष्ट है कि आज तकनीकी दुनिया को शक्तिशाली, डेवलपर-अनुकूल FHE टूलचेन की आवश्यकता है, ताकि FHE-संचालित सफलता की कहानियों को अनलॉक करना शुरू किया जा सके और FHE को तकनीकी प्रवृत्ति से डिजिटल सुरक्षा व्यवसाय में वास्तविक प्रतिमान बदलाव में बदला जा सके। मेरा मानना है कि FHE के बारे में ज्ञान की वर्तमान स्थिति - वैज्ञानिक और तकनीकी दोनों तरह से - वर्तमान में ऐसे उपकरण बनाने और उन्हें बिना किसी देरी के तकनीक-प्रेमी लोगों के लिए उपलब्ध कराने के लिए पहले से ही पर्याप्त है। नई सुविधाओं का निरंतर एकीकरण समय के साथ स्वाभाविक रूप से सामने आएगा, ऐसा हमेशा होता है।

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

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

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

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

इसलिए FHE प्रौद्योगिकी सक्षमकर्ताओं के लिए अंतिम लक्ष्य ऐसे उपकरणों की कल्पना करना और उन्हें वितरित करना है जो न केवल देव मल्टीवर्स में अपने प्राइम टाइम के लिए तैयार हों, बल्कि एक नया उद्योग मानक स्थापित करने के लिए पर्याप्त मजबूत हों। इसे हासिल करने के लिए, उन्हें इस बात पर जोखिम उठाना होगा कि कौन सी FHE योजना उन्हें वहां तक पहुँचाने की अधिक संभावना है।

चलो एक खेल खेलते हैं।

एक डेवलपर को लें जो FHE की पेचीदगियों के बारे में कुछ नहीं जानता लेकिन एक होमोमॉर्फिक एप्लिकेशन बनाना चाहता है। आप यहाँ टूल बिल्डर हैं, आप उस डेवलपर का सामना कर रहे हैं, जिससे आप सामान्य विकास प्रथाओं और कंप्यूटर विज्ञान की मूल बातों से कुछ परिचित होने की उम्मीद कर सकते हैं लेकिन बाकी सब कुछ - उन्नत गणित और इस तरह की चीजें, सीमा से बाहर हैं। आप उन्हें अपने दम पर FHE ऐप बनाने में कैसे सफल बना सकते हैं?

यह लेख TFHE पर दांव लगाकर उस खेल को जीतने के लिए विभिन्न रणनीतियों की पड़ताल करता है।

एप्लिकेशन की प्रकृति के आधार पर - कस्टम डेटा क्रंचिंग, न्यूरल नेटवर्क, स्मार्ट कॉन्ट्रैक्ट या सामान्य-उद्देश्य प्रोग्रामिंग, TFHE-सक्षम विजयी पथों का पता लगाया जाएगा। यह अन्वेषण हमें एक आसान रास्ते, एक कठिन रास्ते और बीच में कुछ अन्य रास्तों पर ले जाएगा, जिनके व्यावहारिक कार्यान्वयन में तकनीकी तत्परता के विभिन्न स्तर होंगे।

टीएफएचई कार्यक्रम क्या हैं?

TFHE का मतलब है टोरस FHE। इसे इसके खोजकर्ताओं के नाम पर CGGI भी कहा जाता है, TFHE FHE परिदृश्य में एक अद्वितीय स्थान रखता है: यह प्रोग्रामेबल बूटस्ट्रैपिंग (PBS) को सक्षम करने के लिए सबसे प्रसिद्ध तंत्र है।

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

टीएफएचई नेटवर्क

टीएफएचई जिस कम्प्यूटेशनल मॉडल की वकालत करता है वह सर्वोत्कृष्ट है।

TFHE प्रोग्राम में प्राथमिक प्रसंस्करण इकाई बिल्कुल न्यूरॉन की तरह दिखती है और 2 बुनियादी होमोमोर्फिक ऑपरेशन बनाती है:

1. इनपुट का एक रैखिक संयोजन जो E(x) लौटाता है जहाँ x = w_1 x_1 + … + w_n x_n modulo m , एन्क्रिप्टेड इनपुट E(x_1), …, E(x_n) और प्लेनटेक्स्ट वेट w_1, …, w_n का एक सेट दिया गया है।

   
   

2. एक पीबीएस जो E(T[x]) की गणना E(x) से करता है जहाँ T आकार m की कुछ सादा पाठ तालिका है।

"TFHE न्यूरॉन" में, m , x_i , w_i , साथ ही प्रविष्टियाँ T[0], …, T[m-1] सभी पूर्णांक हैं, और कोई भी व्यक्ति स्वतंत्र रूप से "पैरामीटर" m , w_1, …, w_n और T चुन सकता है। यह देखते हुए कि रैखिक संयोजन की लागत लगभग शून्य है, दक्षता की बाधा PBS है जिसका चलने का समय पूरी तरह से मापांक m पर निर्भर करता है: m बढ़ने पर गति कम हो जाती है। यह TFHE न्यूरॉन्स में मापांक के लिए छोटे मानों - विषम या सम, लेकिन कम से कम 2 - का उपयोग करने के लिए आमंत्रित करता है, हालांकि उनकी कम्प्यूटेशनल अभिव्यंजना में बहुत अधिक कमी से बचने के लिए एक समझौता अवश्य किया जाना चाहिए।

अब, जिस तरह से समानांतरता और एचपीसी ट्रिक्स से लाभ उठाने के लिए न्यूरल नेटवर्क में न्यूरॉन्स को परतों में इकट्ठा किया जाता है, उसी तरह TFHE नेटवर्क TFHE न्यूरॉन्स की परतों को ढेर करते हैं। प्रत्येक परत में एक सामान्य मापांक m के मॉड्यूलो के वजन मैट्रिक्स और आकार m के लुकअप टेबल का एक वेक्टर होता है। हालाँकि, मापांक पिछली या अगली परत में भिन्न होने के लिए स्वतंत्र है, ठीक उसी तरह जैसे परत का आकार।

और यहीं पर TFHE का काम पूरा हो जाता है! बस, हमें फ़ंक्शन को लुकअप नेटवर्क के रूप में व्यवस्थित रूप से व्यक्त करने की ज़रूरत है। अब हमारे पास हमारा होमोमॉर्फिक कम्प्यूटेशनल मॉडल है।

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

TFHE नेटवर्क को निष्पादन योग्य बनाना

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

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

यह पता लगाना कि कौन से पैरामीटर सेट TFHE नेटवर्क के निष्पादन को अनुकूलित करते हैं, बोझिल हो सकता है, और किसी भी मामले में, विशेषज्ञों के लिए भी - पेन-एंड-पेपर शैली में ऐसा करना बहुत कठिन है, जैसा कि FHE के शुरुआती दिनों में था, क्योंकि सब कुछ एक-दूसरे पर निर्भर करता है। साथ ही, कई इष्टतम सेट एक साथ सह-अस्तित्व में हो सकते हैं, इस प्रकार सार्वजनिक कुंजी आकार, महत्वपूर्ण-पथ विलंबता या अधिकतम थ्रूपुट के बीच मध्यस्थता की आवश्यकता होती है। सौभाग्य से, पिछले वर्षों में इस कार्य को स्वचालित करने की समस्या को हल कर लिया गया है और अब किसी दिए गए TFHE नेटवर्क के सर्वोत्तम क्रिप्टोग्राफ़िक इंस्टेंटिएशन को जल्दी से निर्धारित करने के लिए शक्तिशाली अनुकूलन उपकरण मौजूद हैं।

एक बार क्रिप्टोग्राफिक मापदंडों के साथ स्थापित हो जाने पर, TFHE नेटवर्क सही मायने में निष्पादन योग्य हो जाता है, या अधिक सटीक रूप से, संकलन के उपयुक्त पास के माध्यम से एक सही निष्पादन योग्य बन जाता है।

टीएफएचई कार्यक्रम

TFHE कार्यक्रम पैरामीट्रिज्ड TFHE नेटवर्कों का एक संग्रह है, जो "सादे तर्क" द्वारा एक साथ चिपकाया जाता है।

सादा तर्क बनता है

• सादे पाठ चरों (अर्थात सामान्य, गैर-एन्क्रिप्टेड चर) पर संचालित निर्देश,

• शाखाबद्ध, या तो बिना शर्त या सादे पाठ्य विधेय के लिए सशर्त,

• सादे पाठ पते पर स्मृति पढ़ना और लिखना, सूचक अंकगणित,

• सबरूटीन/फ़ंक्शन के लिए कॉल.

  
  

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

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

TFHE प्रोग्रामों के प्रतिनिधित्व को एकीकृत करने के लिए एक समर्पित भाषा का उपयोग किया जा सकता है - जैसे कुछ DSL, या बेहतर, एक MLIR बोली - ताकि संकलन एक ही बैक-एंड कंपाइलर के साथ किया जा सके।

रनटाइम की सटीक प्रकृति (साझा/गतिशील लाइब्रेरी, VM या अन्यथा) यहाँ केवल एक तौर-तरीका है। कोई भी विकल्प एक परिचालन TFHE-संचालित होमोमॉर्फिक ऐप की ओर ले जाएगा जिसे तैनात किया जा सकता है और उपयोगकर्ताओं के सामने पेश किया जा सकता है।

अब आइये एक मिनट के लिए खेल पर वापस आते हैं।

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

हमारा लक्ष्य तय हो चुका है, हमें बस एक TFHE प्रोग्राम की जरूरत है ताकि हम एक्जीक्यूटेबल तक पहुंच सकें। लेकिन... आखिर हम डेवलपर को TFHE प्रोग्राम जैसी खास चीज खुद कैसे बनाने देंगे?

आसान रास्ता: एक FHE लाइब्रेरी जारी करें और डेवलपर को अपना काम करने दें

यहाँ आसान जीत का रास्ता आता है: आप सभी जटिलताओं को एक ब्लैक-बॉक्स FHE API में समाहित कर देते हैं।

सादा कार्यक्रम

किसी भी प्रोग्रामिंग भाषा में, एक (सादा) प्रोग्राम को मूलतः तीन अवयवों के संयोजन के रूप में देखा जा सकता है:

• प्रोग्रामेटिक तर्क, जो भाषा-मूल निर्देशों और स्कोपिंग संरचनाओं से बना है,

• चर और डेटा प्रकारों का चयन जो प्रोग्राम उन्हें प्रदान करता है, सभी संभावित डेटा प्रकारों में से चुना जाता है,

• सभी उपलब्ध बाह्य फ़ंक्शनों में से चयनित बाह्य फ़ंक्शनों के चयन के लिए कॉल, जिसका उपयोग प्रोग्राम अपने चरों पर संचालन करने के लिए करता है।

  
  

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

अतः सादे प्रोग्राम वास्तव में "सरल" होते हैं:

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

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

अब यह प्रोग्राम सामान्य रूप में "सरल" है। मेरा मतलब है, इतना सरल कि इसे होमोमोर्फिक क्षमताओं के साथ बढ़ाया जा सके।

FHE को चित्र में शामिल करें

आप भाषा-मूलक FHE लाइब्रेरी जारी करके तथा डेवलपर को यह तय करने देकर गेम जीतते हैं कि इसका सर्वोत्तम उपयोग कैसे किया जाए।

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

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

यह डेवलपर के लिए निश्चित रूप से अच्छा काम कर सकता है। खैर... अगर आप लाइब्रेरी प्रदाता के रूप में अपने पक्ष को पूरा करते हैं तो।

वे एक होमोमोर्फिक कार्यक्रम तैयार करेंगे जो अब कुछ इस तरह दिखेगा।

अब सह-अस्तित्व में सादे और एन्क्रिप्टेड चर हैं और प्रोग्राम को इन 2 ऑब्जेक्ट प्रकारों के बीच एक सख्त विभाजन बनाए रखना है। ऐसा इसलिए है क्योंकि यह FHE सुनहरा नियम है जो बताता है कि जब आप सादे और एन्क्रिप्टेड तर्कों के मिश्रण पर फ़ंक्शन लागू करते हैं, तो परिणाम अनिवार्य रूप से एन्क्रिप्टेड होता है, उदाहरण के लिए fhe_add(E(x), y) E(x+y) लौटाता है और इसी तरह। इसलिए सादे चर कुछ FHE फ़ंक्शन में प्रवेश कर सकते हैं लेकिन उनसे कभी बाहर नहीं आ सकते। होमोमॉर्फिक एन्क्रिप्शन कंप्यूटेशन के माध्यम से जिस किसी चीज़ को छूता है उसे "दूषित" करता है।

तो, देखें... फिर आप किसी एन्क्रिप्टेड वेरिएबल को सशर्त रूप से कैसे शाखाबद्ध करते हैं?

खैर, आप ऐसा नहीं कर सकते। लेकिन यह कोई बड़ी बात नहीं है।

एक अड़चन: सशर्त शाखा

FHE एप्लीकेशन में, कंडीशनल ब्रांचिंग केवल सादे बूलियन पर ही काम कर सकती है, एन्क्रिप्टेड पर नहीं। एन्क्रिप्टेड बिट के आधार पर आपको कैसे पता चलेगा कि कहाँ जाना है? आपके पास उस बिट को डिक्रिप्ट करने के लिए उपयोगकर्ता की निजी कुंजी नहीं है।

सौभाग्य से, एफएचई आपको इसके समाधान के लिए सरल उपाय भी बताता है।

यदि को नियमित कैसे करें?

मान लीजिए डेवलपर शुरू में कुछ ऐसा करना चाहता था

 if (x == 0) then y = 3 else z = 7

लेकिन यह पता चलता है कि, उस बिंदु तक, चर x वास्तव में एन्क्रिप्टेड हो जाएगा। कोड के उस हिस्से को कैसे अनुकूलित करें?

सबसे पहले आपको सादे if कथन पर पुनः काम करना होगा, ताकि मल्टीप्लेक्सिंग का उपयोग करने वाले सीधे-सीधे कोड का समतुल्य भाग प्राप्त हो सके:

 bit = (x == 0) // bit = 1 if x == 0 otherwise 0 y = 3 * bit + y * (1 - bit) // y = 3 if bit == 1 otherwise no change z = z * bit + 7 * (1 - bit) // z = 7 if bit == 0 otherwise no change

दूसरे चरण में, डेवलपर को यह तथ्य प्रचारित करना होगा कि x , बाद की पंक्तियों में एन्क्रिप्टेड प्रकार का है:

 bit = fhe_is_equal(x, 0) // bit, y_new and z_new are encrypted y_new = fhe_add(fhe_mul(3, bit), fhe_mul(y, fhe_sub(1, bit))) z_new = fhe_add(fhe_mul(z, bit), fhe_mul(7, fhe_sub(1, bit)))

कोई यह जांच सकता है कि कार्यात्मक रूप से यह देव के प्रारंभिक इरादे के समतुल्य है या नहीं, बस इतना ही।

यदि प्रोग्रामिंग भाषा मूल ऑपरेटरों को ओवरलोड करने की अनुमति देती है, तो FHE API दूसरे स्निपेट के स्पष्ट FHE फ़ंक्शन को भी अनावश्यक बना सकता है, ताकि डेवलपर को केवल पहला पुनर्लेखन ही करना पड़े।

डेवलपर को वाक्यविन्यास की एक अतिरिक्त खुराक देने के लिए, आप एक ओवरलोडेड टर्नरी ऑपरेटर a? b : c भी दिखा सकते हैं जिसमें किसी भी तर्क को एन्क्रिप्ट किया जा सकता है या नहीं। कोड का हिस्सा और भी सरल हो जाता है:

 bit = (x == 0) // bit = 1 if x == 0 otherwise 0 y_new = bit? 3: y // y = 3 if bit == 1 otherwise no change z_new = bit? z: 7 // z = 7 if bit == 0 otherwise no change

यह आसानी से मनमाने if/switch कथनों के लिए सामान्यीकृत हो जाता है: हर बार जब जांचने के लिए एक एन्क्रिप्टेड स्थिति होती है, तो डेवलपर को कथन के कई निकायों को समतुल्य सीधी-रेखा कोड के एक एकल ब्लॉक में जोड़ने के लिए मल्टीप्लेक्सिंग का उपयोग करना होता है।

फॉर/व्हाइल लूप को नियमित कैसे करें

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

 for (i = 0; i < x; i++) do <body> // i is plain, x is encrypted

जहाँ x एन्क्रिप्टेड प्रकार का होना चाहिए। सबसे पहले, इसे एक सादे for कथन और एक अनियमित if कथन में विघटित करें:

 for (i = 0; i < known_max_value_of_x; i++) do if (i < x) then <body> // i is plain, x is encrypted

और फिर if कथन को पहले की तरह नियमित करें:

 for (i = 0; i < known_max_value_of_x; i++) do bit = (i < x) // i is plain, x and bit are encrypted <new_body> // new body regularized using bit? _ : _

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

अंततः, उपरोक्त रूपांतरणों को अनियमित नियंत्रण प्रवाह को नियमित करने के लिए एक व्यवस्थित विधि में आसानी से सामान्यीकृत किया जा सकता है, जिसे कोडर्स के लिए आत्मसात करना और अपनी कोडिंग आदतों में शामिल करना आसान होता है।

उदाहरण: EVM पर गोपनीय स्मार्ट अनुबंध

ज़ामा का fhEVM, एथेरियम वर्चुअल मशीन (EVM) पर गोपनीय स्मार्ट कॉन्ट्रैक्ट के विकास और तैनाती के लिए एक पूर्ण-विकसित ओपन-सोर्स फ्रेमवर्क है। fhEVM कॉन्ट्रैक्ट सरल सॉलिडिटी कॉन्ट्रैक्ट हैं जो पारंपरिक सॉलिडिटी टूलचेन का उपयोग करके बनाए गए हैं। परिचित डेव अनुभव लाइब्रेरी TFHE.sol द्वारा FHE-संवर्धित है जो एन्क्रिप्टेड डेटा प्रकार और मानक फ़ंक्शन के लिए FHE प्रतिस्थापन प्रदान करता है।

वर्तमान में समर्थित एन्क्रिप्टेड डेटा प्रकार हैं

 ebool, euint4, euint8, euint16, euint32, euint64, eaddress

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

 function mint(bytes calldata encryptedAmount) public onlyContractOwner { euint64 amount = TFHE.asEuint64(encryptedAmount); balances[contractOwner] = balances[contractOwner] + amount; totalSupply = totalSupply + amount; }

सॉलिडिटी के मूल ऑपरेटर +, -, *, &, |, ^, etc डेवलपर की सुविधा के लिए ओवरलोड किया गया है, और प्रदान किए गए तुलना ऑपरेटर eq, ne, gt, lt, ge, le एक एन्क्रिप्टेड बूलियन ebool लौटाते हैं। होमोमॉर्फिक टर्नरी ऑपरेटर _? _ : _ को select : कहा जाता है।

 function bid(bytes calldata encryptedBid) internal { euint32 bid = TFHE.asEuint32(encryptedBid); ebool isAbove = TFHE.le(bid, highestBid); // Replace highest bid highestBid = TFHE.select(isAbove, bid, highestBid); }

रनटाइम पक्ष पर, fhEVM एक TFHE-सक्षम EVM प्रदान करता है जहां होमोमोर्फिक फ़ंक्शन पूर्व संकलित अनुबंधों के रूप में प्रदर्शित होते हैं, जो ओपन-सोर्स TFHE-rs Rust लाइब्रेरी के एकीकरण का परिणाम है।

इस पर अधिक जानकारी के लिए fhEVM श्वेत पत्र देखें।

TFHE के साथ FHE API बनाने के लिए क्या करना पड़ता है?

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

पहली आवश्यकता यह सुनिश्चित करना है कि प्रोग्राम लॉजिक "सादा" हो। यही वह बात है जो हमने डेवलपर को उनके नियंत्रण प्रवाह कथनों को नियमित करके स्वयं तैयार करना सिखाया। तो अब हम वास्तव में उस पर अच्छे हैं।

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

1. आपको अपने API फ़ंक्शन के लिए TFHE नेटवर्क बनाने की आवश्यकता है

किसी दिए गए फ़ंक्शन को कार्यान्वित करने वाले पैरामीट्रिज्ड TFHE नेटवर्क को पूर्व-स्थापित करना आवश्यक रूप से आसान नहीं है।

2 एन्क्रिप्टेड 64-बिट अहस्ताक्षरित पूर्णांकों का होमोमोर्फिक जोड़ बनाने से आपको कई तकनीकी विकल्प मिलते हैं: आप 64-बिट इनपुट को मॉड्यूलर पूर्णांकों के सदिशों के रूप में कैसे प्रस्तुत करते हैं? किस मॉड्यूलस (या कई मॉड्यूल) के साथ? और फिर आप टेबल लुकअप की परतों के साथ 64-बिट जोड़ सर्किट को कैसे साकार करते हैं?

वहाँ बहुत सारे विकल्प हैं। लेकिन आप अंततः अच्छी इंजीनियरिंग और बहुत सारे प्रयोगों के माध्यम से अपना मन बना लेंगे।

2. आपको एन्क्रिप्टेड डेटा प्रकारों को सामान्य करने की आवश्यकता है

मान लीजिए कि आपने API के सभी कार्यों के लिए TFHE नेटवर्क को क्रियान्वित किया है, तो आप यह सुनिश्चित करना चाहेंगे कि उन्हें लेगो ब्लॉकों की तरह इच्छानुसार बनाया जा सके।

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

पुनः, वहां कई विकल्प हैं, और आपको उनके बीच मध्यस्थता करने की आवश्यकता होगी।

3. आपको वास्तविक संयोजनशीलता सुनिश्चित करने की आवश्यकता है

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

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

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

तो फिर एफएचई लाइब्रेरी पर्याप्त अच्छी क्यों नहीं होगी?

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

लेकिन वे उन कार्यक्रमों के लिए पर्याप्त नहीं हो सकते हैं जो विशेषज्ञता रखते हैं

• मशीन लर्निंग में बड़े, गणना-गहन कार्य,

• कस्टम, गैर-मानक कार्य.

  
  

यही वह समय है जब होमोमोर्फिक संकलन आता है।

कठिन रास्ता: होमोमॉर्फिक कंपाइलर जारी करना

कठिन रास्ता यहीं से शुरू होता है: सामान्य प्रयोजन प्रोग्रामिंग के बाहर खेल जीतने के लिए, अब आपको एक TFHE कंपाइलर प्रदान करना होगा।

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

आइए गैर-मानक अनुप्रयोगों के विशिष्ट उदाहरणों पर नजर डालें।

गहन तंत्रिका नेटवर्क के साथ गोपनीय अनुमान

एक साधारण तंत्रिका नेटवर्क को होमोमोर्फिक समतुल्य में बदलकर, डेवलपर एक होमोमोर्फिक अनुमान सेवा का निर्माण और परिनियोजन करेगा, जिसमें उपयोगकर्ता इनपुट और आउटपुट एंड-टू-एंड एन्क्रिप्टेड होंगे।

देव इनपुट के रूप में क्या प्रदान करता है

डेवलपर से यह अपेक्षा की जाती है कि वह मशीन लर्निंग के बारे में इतना अच्छी तरह से जानता हो कि वह एक प्रशिक्षित क्वांटाइज्ड मॉडल तैयार कर सके, या उसके पास पहले से ही एक मॉडल हो।

क्वांटाइजेशन कैसे किया जाता है, इसकी विशिष्टताएँ यहाँ वास्तव में मायने रखती हैं, क्योंकि आपके कंपाइलर को मॉडल को मूल रूप से TFHE नेटवर्क होने की आवश्यकता होगी - या एक सरल पुनर्लेखन के माध्यम से आसानी से एक के लिए अनुकूल होना चाहिए। उपलब्ध ओपन-सोर्स तकनीकें क्वांटाइजेशन के उस रूप का समर्थन करने के लिए जानी जाती हैं, या तो पहले से प्रशिक्षित मॉडल को पोस्ट-क्वांटाइज़ करके, या अधिमानतः क्वांटाइजेशन-अवेयर ट्रेनिंग (QAT) करके, जो एक ही डेटासेट पर प्रशिक्षित गैर-क्वांटाइज्ड मॉडल की तुलना में सटीकता के अत्याधुनिक स्तर को प्राप्त करता है।

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

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

TFHE नेटवर्क को पैरामीटराइज़ करने के लिए क्या करना पड़ता है?

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

TFHE नेटवर्क के क्रिप्टोग्राफ़िक मापदंडों में स्वतंत्रता की बहुत अधिक डिग्री होती है, इसलिए उन सभी को बलपूर्वक लागू करना संभव नहीं होता। साथ ही, अनुकूलन के लिए मीट्रिक 2 घटकों पर निर्भर करते हैं जो नेटवर्क से पूरी तरह से बाहरी होते हैं और उन एल्गोरिदम पर निर्भर करते हैं जिनका उपयोग रनटाइम निम्न-स्तरीय TFHE संचालन करने के लिए करता है:

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

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

  
  

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

तकनीकी तत्परता

अच्छे विज्ञान और इंजीनियरिंग ने इस प्रकार की अनुकूलन समस्याओं को कुछ ही सेकंड में हल कर दिया है, और कंक्रीट जैसे TFHE कम्पाइलर में पहले से ही एक आंतरिक मॉड्यूल के रूप में एक कुशल TFHE पैरामीटर अनुकूलक मौजूद है।

विभिन्न सुधारों से भविष्य में TFHE अनुकूलकों को और भी अधिक तीव्र बनाया जा सकता है, लेकिन इनके बिना भी, TFHE नेटवर्कों के पैरामीटरीकरण को - काफी हद तक - एक पूर्ण कार्य माना जा सकता है।

उच्च गति कस्टम डेटा क्रंचिंग

देव इनपुट के रूप में क्या प्रदान करता है

ये अनुप्रयोग पूरी तरह से अलग तरह के होते हैं। डेवलपर के पास लागू करने के लिए एक कस्टम फ़ंक्शन का गणितीय विनिर्देश होता है, साथ ही एक परिशुद्धता बाधा भी होती है। उदाहरण के लिए,

जहाँ x , 0 और 1 के बीच की एक वास्तविक संख्या है, और F का सन्निकटन G का उपयोग तब तक स्वीकार्य है जब तक

डेवलपर को पता है कि मानक API फ़ंक्शनों की रचना करके लिफाफे के पीछे G लागू करना संभवतः बहुत ही कमतर होगा।

आपका कंपाइलर जो करेगा वह है - तुरंत एक नया TFHE नेटवर्क तैयार करना जो विशेष रूप से G के विनिर्देश को पूरा करने के लिए डिज़ाइन किया गया है। फिर यह इसे पैरामीट्रिज करेगा और होमोमोर्फिक ऐप बनाने के लिए बैक-एंड संकलन के साथ आगे बढ़ेगा।

TFHE नेटवर्क को संश्लेषित करने में क्या लगता है?

वर्तमान समय में, इस बारे में वैज्ञानिक ज्ञान की कमी है कि TFHE नेटवर्क, जिसकी सटीक परिभाषा मैंने पहले बताई है, को स्वचालित रूप से कैसे संश्लेषित किया जा सकता है। यहां तक कि आसन्न प्रकार के सर्किट के संश्लेषण पर शोध भी जो पूर्णांक-मूल्यवान मॉड्यूलर अंकगणित पर निर्भर करता है, सबसे खराब है। इस कार्य को A से Z तक पूरा करने में सक्षम किसी भी पहले से मौजूद सिंथेसाइज़र का उल्लेख नहीं किया गया है।

बूलियन संश्लेषण का लाभ उठाना

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

द्वारा

• इसके इनपुट की संख्या 3 निर्धारित करना तथा x_1, x_2, x_3 0/1 मान पर लागू करना,
• इसका मापांक m = 4 और इसका भार (w_1, w_2, w_3) = (2, -1, 1) पर सेट करना,
• इसकी लुकअप तालिका को [0, 1, 1, 0] पर सेट करना।

सभी संभावित भार और तालिकाओं को समान मापांक के साथ बलपूर्वक लागू करके, कोई व्यक्ति TFHE न्यूरॉन्स की एक डिक्शनरी बना सकता है जो टर्नरी गेट्स की गणना करने में सहायक हो सकती है। अगला चरण है

• डेवलपर के विनिर्देश से बूलियन सर्किट उत्पन्न करने के लिए बूलियन संश्लेषण उपकरण का उपयोग करना (ऐसा करने के लिए कई ओपन-सोर्स उपकरण उपलब्ध हैं),
• शब्दकोश से संबंधित त्रिक गेटों में सर्किट को काटना (उर्फ 3-तरफ़ा LUT विभाजन),
• इन त्रिक द्वारों को समतुल्य न्यूरॉन्स द्वारा प्रतिस्थापित करना,
• सर्किट को न्यूनतम गहराई के स्तरित नेटवर्क में पुनः आकार देना।

यह कई में से सिर्फ़ एक उदाहरणात्मक रणनीति है क्योंकि बूलियन सर्किट पर निर्भर रहने वाले तरीके बहुत हैं। आप सिर्फ़ सामान्य बाइनरी गेट्स पर विचार कर सकते हैं और उन्हें सीमित TFHE न्यूरॉन्स के साथ लागू कर सकते हैं। CEA के सिंगुलता और - बाद में - Google के FHE ट्रांसपाइलर ने TFHE के साथ उस रास्ते पर सटीक रूप से काम किया है।

तकनीकी तत्परता

बूलियन संश्लेषण आक्रामक सर्किट अनुकूलन तकनीकों का उपयोग करता है, और कुल मिलाकर यह एक हल किया गया तकनीकी मुद्दा है - या काफी हद तक हल किया गया है, जिससे यह दृष्टिकोण संकलक बनाने वाले के लिए ध्वनि और व्यावहारिक बन जाता है।

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

लेकिन फिर भी, यह स्पष्ट रूप से पहचानने के लिए और अधिक शोध की आवश्यकता है कि ऐसा कैसे किया जाए। यह संभव है कि पूरी तरह से अलग दृष्टिकोण, जैसे कि मशीन लर्निंग से उधार ली गई कुछ उपयुक्त प्रशिक्षण पद्धति के साथ TFHE नेटवर्क सीखना, बेहतर परिणाम प्रदान करेगा। समय ही बताएगा।

एक सर्व-समावेशी TFHE संकलक की खोज

यह मानते हुए कि हमारी संश्लेषण समस्या हल हो गई है और कुशल कस्टम TFHE नेटवर्क प्राप्त होता है, आप स्वयं को सभी गतिशील भागों को एक साथ रखने और एक ऐसा कंपाइलर डिजाइन करने के लिए तैयार पाएंगे जो पूरा काम कर सके:

1. यह इनपुट के रूप में एक सादा प्रोग्राम लेगा, जहां संवेदनशील चरों को केवल एन्क्रिप्टेड के रूप में एनोटेट किया जाएगा।

2. यह पूर्व-प्रशिक्षित न्यूरल नेटवर्क या अन्य मशीन लर्निंग मॉडल को स्वीकार करेगा और उन्हें TFHE नेटवर्क के रूप में पुनर्व्याख्या करेगा।

3. यह गणितीय विनिर्देश के आधार पर तैयार किए गए फ़ंक्शन मॉक-अप को स्वीकार करेगा और कस्टम TFHE नेटवर्क बनाने के लिए तत्काल संश्लेषण करेगा।

4. यह संकलन इकाई में लटके सभी गैर-पैरामीटरीकृत TFHE नेटवर्कों को, जब भी आवश्यक हो, अनुकूलक मॉड्यूल का उपयोग करके निष्पादन योग्य उदाहरणों में बदल देगा।

5. यह विभिन्न लक्ष्य TFHE रनटाइम्स या/और हार्डवेयर आर्किटेक्चर के लिए संकलन के बैक-एंड चरण का निष्पादन करेगा।

6. यह तीव्र TFHE नेटवर्कों के संश्लेषण और पैरामीटरीकरण को सक्षम करने के लिए विशिष्ट हार्डवेयर त्वरक (उनके लागत मॉडल के माध्यम से) का लाभ उठाएगा।

   
   

हां, आप नियंत्रण प्रवाह के स्वचालित नियमितीकरण के लिए कुछ समर्थन भी दे सकते हैं, ताकि डेवलपर को इसके बारे में और अधिक चिंता न करनी पड़े।

इससे एफएचई ऐप बिल्डरों को सर्वोत्तम विकास अनुभव प्राप्त होगा।

सारांश

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

TFHE विशिष्ट संकलन तकनीकों में अग्रणी है, जो डेवलपर की आवश्यकताओं को उस बिंदु से आगे भी संतुष्ट कर सकती है, विशेष रूप से एन्क्रिप्टेड मशीन लर्निंग इंफरेंस के लिए, और आगामी वर्षों में, उच्च गति एन्क्रिप्टेड डेटा क्रंचिंग और अन्य कस्टम FHE अनुप्रयोगों के लिए।

कुल मिलाकर, TFHE अधिक एकीकृत और अनुकूली FHE टूलचेन बनाने के लिए एक स्पष्ट प्रौद्योगिकी मार्ग प्रदान करता है, जो सॉफ्टवेयर विकास की दुनिया में बड़ा नाम बन सकता है, और गोपनीयता-प्रथम समाधानों की एक नई लहर को जन्म दे सकता है, जिसे कोई भी अभूतपूर्व आसानी से बना और चला सकता है।

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

कौन से और कब, यह एक अलग कहानी है। लेकिन उस कहानी के पीछे गोपनीय कंप्यूटिंग के भविष्य के बारे में कई अन्य रोमांचक और संभावित रूप से ज्ञानवर्धक प्रश्न छिपे हुए हैं।