परिचय: प्रमाणीकरणको लागि मार्ग

Web3 को मुख्य फाइदा प्रमाणीकरण हो - प्रयोगकर्ताहरूले प्रणालीहरू वास्तवमा कसरी सञ्चालन गर्छन् भनेर प्रमाणित गर्न सक्छन्। यो सुविधाले क्रिप्टो उद्योग भित्र र बाहिर धेरैले वेब३ लाई थप पारदर्शी र प्रमाणिकरणयोग्य इन्टरनेट तर्फको एउटा कदमको रूपमा वर्णन गरेको छ।

फेसबुक वा इन्स्टाग्राम जस्ता Web2 प्लेटफर्महरू विपरीत, जहाँ एल्गोरिदम र नियमहरू कागजात भए तापनि अपारदर्शी रहन्छन्, क्रिप्टो प्रोटोकलहरू पूर्ण लेखापरीक्षणको लागि डिजाइन गरिएका छन्। यदि तिनीहरू साझेदारी गरिएका छन् भने, तपाइँसँग प्लेटफर्म निर्दिष्ट रूपमा सञ्चालन हुन्छ कि भनेर प्रमाणित गर्ने क्षमताको कमी छ। यो क्रिप्टोको विपरित हो, जहाँ प्रत्येक प्रोटोकललाई सम्भव भएसम्म लेखापरीक्षण गर्न मिल्ने गरी डिजाइन गरिएको छ — वा कमसेकम, यो हुने अपेक्षा गरिएको छ।

आज, हामी "The Verge" को अन्वेषण गर्नेछौं, Ethereum को भविष्य मा Vitalik को हालै प्रकाशित छ-भाग श्रृंखला को एक खण्ड, Ethereum ले भविष्यमा प्रमाणीकरण, स्थिरता, र स्केलेबिलिटी हासिल गर्न तर्फ चालेका कदमहरु को विश्लेषण गर्न। "द भर्ज" शीर्षक अन्तर्गत, हामी कसरी ब्लकचेन आर्किटेक्चरहरूलाई थप प्रमाणिकरण गर्न सकिन्छ, यी परिवर्तनहरूले प्रोटोकल स्तरमा ल्याउने नवाचारहरू, र उनीहरूले प्रयोगकर्ताहरूलाई कसरी अझ सुरक्षित पारिस्थितिकी प्रणाली प्रदान गर्छन् भन्ने विषयमा छलफल गर्नेछौं। सुरु गरौं!

"प्रमाणीकरण" भनेको के हो?

Web2 अनुप्रयोगहरूले "ब्ल्याक बक्सहरू" को रूपमा कार्य गर्दछ - प्रयोगकर्ताहरूले तिनीहरूको इनपुटहरू र नतिजा आउटपुटहरू मात्र हेर्न सक्छन्, अनुप्रयोगले वास्तवमा कसरी काम गर्दछ भन्ने कुनै दृश्यता बिना। यसको विपरित, क्रिप्टोकरेन्सी प्रोटोकलहरूले सामान्यतया तिनीहरूको स्रोत कोड सार्वजनिक रूपमा उपलब्ध गराउँदछ, वा कम्तीमा त्यसो गर्ने योजनाहरू छन्। यो पारदर्शिताले दुईवटा उद्देश्यहरू पूरा गर्दछ: यसले प्रयोगकर्ताहरूलाई प्रोटोकलको कोडसँग सीधै अन्तरक्रिया गर्न अनुमति दिन्छ यदि तिनीहरूले छनोट गर्छन्, र यसले उनीहरूलाई प्रणाली कसरी सञ्चालन गर्छ र कुन नियमहरूले यसलाई नियन्त्रण गर्छ भनेर बुझ्न मद्दत गर्दछ।

"तपाईंले के गर्न सक्नुहुन्छ विकेन्द्रीकरण गर्नुहोस्, बाँकी प्रमाणित गर्नुहोस्।"

प्रमाणिकरणता सुनिश्चित गर्दछ कि प्रणालीहरू उत्तरदायी छन् र, धेरै अवस्थामा, ग्यारेन्टी गर्दछ कि प्रोटोकलहरू उद्देश्य अनुसार कार्य गर्दछ। यो सिद्धान्तले केन्द्रीकरणलाई न्यूनीकरण गर्ने महत्त्वलाई हाइलाइट गर्दछ, किनकि यसले प्रायः अपारदर्शी, गैरजिम्मेवार संरचनाहरू निम्त्याउँछ जहाँ प्रयोगकर्ताहरूले सञ्चालनहरू प्रमाणित गर्न सक्दैनन्। यसको सट्टा, हामीले सकेसम्म विकेन्द्रीकरण गर्ने प्रयास गर्नुपर्छ र विकेन्द्रीकरण सम्भव नभएको ठाउँमा बाँकी रहेका तत्वहरूलाई प्रमाणित र जवाफदेही बनाउनु पर्छ।

Ethereum समुदायले यस परिप्रेक्ष्यमा पङ्क्तिबद्ध गरेको देखिन्छ, किनकि रोडम्यापमा एक माइलस्टोन ("The Verge" भनिन्छ) समावेश गरिएको छ जसलाई Ethereum लाई अझ प्रमाणित गर्न मिल्छ। यद्यपि, भर्जमा डुब्न अघि, हामीले ब्लकचेनका कुन पक्षहरू प्रमाणित गरिनुपर्छ र कुन भागहरू प्रयोगकर्ताहरूको दृष्टिकोणबाट महत्त्वपूर्ण छन् भनेर बुझ्न आवश्यक छ।

ब्लकचेनहरू अनिवार्य रूपमा विश्वव्यापी घडीको रूपमा काम गर्छन्। लगभग 10,000 कम्प्यूटरहरू भएको वितरित नेटवर्कमा, लेनदेनको लागि उत्पत्ति नोडबाट अन्य सबै नोडहरूमा प्रचार गर्न यसले महत्त्वपूर्ण समय लिन सक्छ। यस कारणले गर्दा, नेटवर्कभरका नोडहरूले लेनदेनको सही क्रम निर्धारण गर्न सक्दैनन्-चाहे एउटा पहिले वा अर्को पछि आइपुगेको हो-किनकि तिनीहरूको आफ्नै व्यक्तिपरक दृष्टिकोणहरू छन्।

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

सहमति तहभन्दा बाहिर, त्यहाँ कार्यान्वयन तह पनि छ जुन प्रत्येक ब्लकचेनमा अवस्थित छ। कार्यान्वयन तह प्रयोगकर्ताहरू कार्यान्वयन गर्न चाहने लेनदेनहरूद्वारा आकारको हुन्छ। एकचोटि लेनदेनहरू सफलतापूर्वक सहमतिद्वारा अर्डर गरिसकेपछि, प्रत्येक लेनदेनलाई कार्यान्वयन तहमा हालको स्थितिमा लागू गरिनुपर्छ। यदि तपाइँ सोचिरहनु भएको छ, "राज्य के हो?", तपाइँले सम्भवतः डाटाबेसको तुलनामा ब्लकचेनहरू देख्नुभएको छ - वा विशेष रूपमा, बैंकको डाटाबेसमा किनभने ब्लकचेनहरू, जस्तै बैंकहरू, सबैको ब्यालेन्सको रेकर्ड राख्छन्।

यदि तपाईंसँग राज्यमा $100 छ भने हामीले "S" लाई कल गर्छौं र अरू कसैलाई $10 पठाउन चाहन्छौं भने, अर्को राज्य "S+1" मा तपाईंको ब्यालेन्स $90 हुनेछ। एक राज्यबाट अर्को राज्यमा सार्नको लागि लेनदेन लागू गर्ने यो प्रक्रियालाई हामीले STF (स्टेट ट्रान्जिसन फंक्शन) भनिन्छ।

Bitcoin मा, STF मुख्यतया सन्तुलन परिवर्तनहरूमा सीमित छ, यसलाई अपेक्षाकृत सरल बनाउँदै। यद्यपि, बिटकोइनको विपरीत, इथरियमको STF धेरै जटिल छ किनभने Ethereum कोड चलाउन सक्षम कार्यान्वयन तहको साथ पूर्ण रूपमा प्रोग्रामयोग्य ब्लकचेन हो।

ब्लकचेनमा, त्यहाँ तीनवटा आधारभूत कम्पोनेन्टहरू छन् जुन तपाईंलाई आवश्यक छ — वा सक्षम छन् — प्रमाणित गर्न:

1. राज्य : तपाईले ब्लकचेनमा डाटाको एक टुक्रा पढ्न चाहानुहुन्छ, तर तपाईले पूर्ण नोड चलाउनुहुन्न किनभने राज्यमा पहुँच छैन। तसर्थ, तपाईले RPC (रिमोट प्रोसिजर कल) प्रदायक जस्तै Alchemy वा Infura मार्फत डेटा अनुरोध गर्नुहुन्छ। यद्यपि, तपाईंले RPC प्रदायकद्वारा डाटा छेड़छाड गरिएको छैन भनी प्रमाणित गर्नुपर्छ।
2. कार्यान्वयन : पहिले उल्लेख गरिए अनुसार, ब्लकचेनहरूले STF प्रयोग गर्दछ। तपाईंले राज्य ट्रान्जिसन सही रूपमा कार्यान्वयन भएको थियो भनेर प्रमाणित गर्नुपर्छ — प्रति-लेनदेन आधारमा होइन तर ब्लक-द्वारा-ब्लक आधारमा।
3. सहमतिहरू : तेस्रो-पक्ष संस्थाहरू, जस्तै RPCs, ले तपाईंलाई वैध ब्लकहरू प्रदान गर्न सक्छ जुन अझै ब्लकचेनमा समावेश गरिएको छैन। तसर्थ, तपाईंले यी ब्लकहरू सहमतिबाट स्वीकार गरी ब्लकचेनमा थपिएका छन् भनी प्रमाणित गर्नुपर्छ।

म

यदि यो भ्रामक वा अस्पष्ट देखिन्छ, चिन्ता नगर्नुहोस्। हामी यी प्रत्येक पक्षहरू विस्तारमा जानेछौं। ब्लकचेन अवस्था कसरी प्रमाणित गर्ने भनेर सुरु गरौं!

ब्लकचेन अवस्था कसरी प्रमाणित गर्ने?

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

प्रत्येक इथरियम ब्लकले एउटा मान समावेश गर्दछ जुन त्यो ब्लक पछि नेटवर्कको हालको अवस्था संक्षेप गर्दछ: stateRoot । यो मान 64-क्यारेक्टर ह्यास सहितको सम्पूर्ण इथरियम राज्यको संकुचित प्रतिनिधित्व हो।

प्रत्येक नयाँ लेनदेनले राज्यलाई परिमार्जन गर्दा, त्यसपछिको ब्लकमा रेकर्ड गरिएको स्टेटरूट तदनुसार अद्यावधिक हुन्छ। यो मान गणना गर्न, Ethereum मान्यकर्ताहरूले राज्यका विभिन्न भागहरूलाई व्यवस्थित गर्न र संक्षेप गर्न केकक ह्यास प्रकार्य र मर्कल ट्री भनिने डेटा संरचनाको संयोजन प्रयोग गर्छन्।

ह्यास प्रकार्यहरू एक-तर्फी कार्यहरू हुन् जसले इनपुटलाई निश्चित-लम्बाइ आउटपुटमा रूपान्तरण गर्दछ। Ethereum मा, Keccak जस्ता ह्यास प्रकार्यहरू डेटाको सारांशहरू उत्पन्न गर्न प्रयोग गरिन्छ, इनपुटको लागि फिंगरप्रिन्टको रूपमा सेवा गर्दै। ह्यास प्रकार्यहरूमा चार आधारभूत गुणहरू छन्:

1. निश्चयवाद : एउटै इनपुटले सधैं उही आउटपुट उत्पादन गर्नेछ।
2. फिक्स्ड आउटपुट लम्बाइ : इनपुटको लम्बाइ जेसुकै भए पनि, आउटपुट लम्बाइ सधैं स्थिर हुन्छ।
3. एकतर्फी सम्पत्ति : आउटपुटबाट मूल इनपुट प्राप्त गर्न व्यावहारिक रूपमा असम्भव छ।
4. विशिष्टता : इनपुटमा सानो परिवर्तनले पनि पूर्ण रूपमा फरक आउटपुट उत्पादन गर्दछ। यसरी, एक विशिष्ट इनपुट नक्सा व्यावहारिक रूपमा अद्वितीय आउटपुटमा।

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

यद्यपि, Ethereum मान्यकर्ताहरूले यसको सारांश फेला पार्नको लागि सम्पूर्ण राज्यलाई सीधा ह्यास गर्दैनन्। ह्यास प्रकार्यहरूको एकतर्फी प्रकृतिको कारणले, राज्यलाई सीधै ह्यास गर्नाले प्रमाणीकरणलाई हटाउनेछ, किनकि ह्यास पुन: उत्पादन गर्ने एक मात्र तरिका सम्पूर्ण राज्यको स्वामित्वमा हुनेछ।

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

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

1. लीफ नोडहरू : यी नोडहरूमा व्यक्तिगत डेटा टुक्राहरूको ह्यासहरू हुन्छन् र रूखको तल्लो तहमा अवस्थित हुन्छन्। प्रत्येक पात नोडले मर्कल रूखमा डेटाको एक विशेष टुक्राको ह्यासलाई प्रतिनिधित्व गर्दछ।
2. शाखा नोडहरू : यी नोडहरूमा तिनीहरूको चाइल्ड नोडहरूको संयुक्त ह्यासहरू हुन्छन्। उदाहरणका लागि, बाइनरी मर्कल रूखमा (जहाँ N=2), दुईवटा चाइल्ड नोडहरूको ह्यासहरू जोडिन्छन् र उच्च स्तरमा शाखा नोडको ह्यास उत्पादन गर्न फेरि ह्यास गरिन्छ।
3. रूट नोड : रूट नोड मर्कल रूखको शीर्ष स्तरमा छ र सम्पूर्ण रूखको क्रिप्टोग्राफिक सारांश प्रतिनिधित्व गर्दछ। यो नोड रूख भित्र सबै डाटाको अखण्डता र शुद्धता प्रमाणित गर्न प्रयोग गरिन्छ।

यदि तपाइँ यस्तो रूख कसरी निर्माण गर्ने भनेर सोच्दै हुनुहुन्छ भने, यसले केवल दुई सरल चरणहरू समावेश गर्दछ:

• लीफ नोड सिर्जना : डेटाको प्रत्येक टुक्रा ह्यास प्रकार्य मार्फत प्रशोधन गरिन्छ, र परिणामस्वरूप ह्यासहरूले पात नोडहरू बनाउँछ। यी नोडहरू रूखको तल्लोपश्चिमी स्तरमा रिसिभ हुन्छन् र डेटाको क्रिप्टोग्राफिक सारांश प्रतिनिधित्व गर्दछ।

• कम्बाइन र ह्यास : लीफ नोड्सका ह्यासहरू समूहबद्ध हुन्छन् (जस्तै, जोडीहरूमा) र संयुक्त, त्यसपछि ह्यासिङ। यस प्रक्रियाले अर्को स्तरमा शाखा नोडहरू सिर्जना गर्दछ। एउटै प्रक्रिया शाखा नोडहरूको लागि दोहोर्याइएको छ जबसम्म एकल ह्यास बाँकी रहन्छ।

रूखको शीर्षमा प्राप्त अन्तिम ह्यासलाई मर्कल रूट भनिन्छ। मर्कल रूटले सम्पूर्ण रूखको क्रिप्टोग्राफिक सारांशलाई प्रतिनिधित्व गर्दछ र डेटा अखण्डताको सुरक्षित प्रमाणीकरणको लागि अनुमति दिन्छ।

Ethereum को अवस्था प्रमाणित गर्न हामी कसरी Merkle roots प्रयोग गर्छौं?

मर्कल प्रमाणहरूले ब्लक हेडरमा भण्डारण गरिएको मर्कल रूटमा लक्षित डाटा (एक पात नोड) बाट मार्ग सिर्जना गर्ने ह्यास मानहरूको श्रृंखला प्रदान गरेर डाटाका विशिष्ट टुक्राहरूलाई प्रभावकारी रूपमा प्रमाणित गर्न प्रमाणिकरणकर्तालाई सक्षम बनाउँछ। मध्यवर्ती ह्यासहरूको यो श्रृंखलाले प्रमाणिकरणकर्तालाई सम्पूर्ण राज्य ह्यास नगरी डेटाको प्रामाणिकता पुष्टि गर्न अनुमति दिन्छ।

विशिष्ट डेटा बिन्दुबाट सुरु गर्दै, प्रमाणिकरणकर्ताले यसलाई मर्कल प्रमाणमा प्रदान गरिएको प्रत्येक "भाइबहिनी" ह्याससँग जोड्दछ र तिनीहरूलाई चरण-दर-चरण रूखमा ह्यास गर्दछ। एकल ह्यास उत्पादन नभएसम्म यो प्रक्रिया जारी रहन्छ। यदि यो कम्प्युटेड ह्यास भण्डार गरिएको मर्कल रूटसँग मेल खान्छ भने, डाटा वैध मानिन्छ; अन्यथा, प्रमाणिकरणकर्ताले डेटा दावी गरिएको अवस्थासँग मेल खाँदैन भनेर निर्धारण गर्न सक्छ।

उदाहरण: मर्कल प्रमाणको साथ डाटा पोइन्ट प्रमाणित गर्दै

मानौं हामीले RPC बाट डाटा #4 प्राप्त गरेका छौं र मर्कल प्रमाण प्रयोग गरेर यसको प्रामाणिकता प्रमाणित गर्न चाहन्छौं। यो गर्नको लागि, RPC ले मर्कल रूटमा पुग्न आवश्यक बाटोमा ह्यास मानहरूको सेट प्रदान गर्नेछ। डाटा 4 को लागि, यी भाइबहिनी ह्यासहरूले ह्यास #3, ह्यास #12, र ह्यास #5678 समावेश गर्दछ।

1. डाटा 4 बाट सुरु गर्नुहोस् : पहिले, हामी ह्यास #4 प्राप्त गर्न डाटा #4 ह्यास गर्छौं।
2. भाइबहिनीसँग मिलाउनुहोस् : त्यसपछि हामी ह्यास #4 लाई ह्यास #3 (पत्ता स्तरमा यसको दाजुभाइ) सँग संयोजन गर्छौं र ह्यास #34 उत्पादन गर्न तिनीहरूलाई सँगै ह्यास गर्छौं।
3. रूख माथि सार्नुहोस् : त्यसपछि, हामी ह्यास #34 लिन्छौं र ह्यास #12 सँग जोड्छौं (यसको अर्को स्तर माथि) र ह्यास #1234 प्राप्त गर्न ह्यास गर्छौं।
4. अन्तिम चरण : अन्तमा, हामी ह्यास #1234 लाई ह्यास #5678 (अन्तिम दाजुभाइ प्रदान गरिएको) सँग जोड्छौं र तिनीहरूलाई सँगै ह्यास गर्छौं। परिणामित ह्यासले ब्लक हेडरमा भण्डारण गरिएको मर्कल रूट (ह्यास #12345678) सँग मेल खानुपर्छ।

यदि कम्प्युटेड मर्कल रूटले ब्लकको स्टेट रूटसँग मेल खान्छ भने, हामी डेटा #4 वास्तवमा यो राज्य भित्र मान्य छ भनेर पुष्टि गर्छौं। यदि होइन भने, हामीलाई थाहा छ कि डेटा दाबी गरिएको राज्यसँग सम्बन्धित छैन, सम्भावित छेडछाडलाई संकेत गर्दै। तपाईंले देख्न सक्नुहुने रूपमा, सबै डाटाको ह्यासहरू प्रदान नगरी वा स्क्र्याचबाट सम्पूर्ण मर्कल ट्री पुन: निर्माण गर्न प्रमाणिकरणकर्तालाई आवश्यक नभई, प्रोभरले प्रमाणित गर्न सक्छ कि डाटा #4 राज्यमा अवस्थित छ र यसको यात्राको क्रममा परिवर्तन गरिएको छैन — केवल तीन प्रयोग गरेर। ह्यासहरू। यो मुख्य कारण हो किन मर्कल प्रमाणहरू कुशल मानिन्छ।

जबकि Merkle Trees Ethereum जस्ता ठूला ब्लकचेन प्रणालीहरूमा सुरक्षित र कुशल डाटा प्रमाणिकरण प्रदान गर्नमा निस्सन्देह प्रभावकारी छन्, के तिनीहरू वास्तवमै पर्याप्त कुशल छन्? यसको जवाफको लागि, हामीले मार्कल ट्री प्रदर्शन र साइजले प्रोभर-भेरिफायर सम्बन्धलाई कसरी प्रभाव पार्छ भनेर विश्लेषण गर्नुपर्छ।

मर्कल रूख प्रदर्शनलाई असर गर्ने दुई मुख्य कारकहरू

1. ब्रान्चिङ फ्याक्टो r: प्रति शाखा चाइल्ड नोडहरूको संख्या।
2. कुल डाटा साइज : रूखमा प्रतिनिधित्व गरिएको डेटासेटको आकार।

शाखा कारक को प्रभाव:

यसको प्रभाव राम्रोसँग बुझ्नको लागि एउटा उदाहरण प्रयोग गरौं। शाखा कारकले रूखको प्रत्येक नोडबाट कतिवटा शाखाहरू निस्कन्छ भनेर निर्धारण गर्दछ।

• सानो शाखा कारक (जस्तै, बाइनरी मर्कल ट्री) : यदि बाइनरी मर्कल ट्री (२ को शाखा कारक) प्रयोग गरिन्छ, प्रमाण आकार धेरै सानो हुन्छ, प्रमाणिकरण प्रक्रियालाई प्रमाणिकरणकर्ताको लागि अझ प्रभावकारी बनाउँछ। प्रत्येक नोडमा केवल दुईवटा शाखाहरूको साथ, प्रमाणिकरणकर्ताले प्रति स्तर एक भाई ह्यासलाई मात्र प्रशोधन गर्न आवश्यक छ। यसले प्रमाणीकरणलाई गति दिन्छ र कम्प्युटेसनल लोड कम गर्छ। यद्यपि, घटाइएको शाखाको कारकले रूखको उचाइ बढाउँछ, रूख निर्माणको क्रममा थप ह्यासिङ अपरेशनहरू आवश्यक पर्दछ, जुन प्रमाणीकरणकर्ताहरूको लागि बोझ हुन सक्छ।
• ठूलो शाखा कारक (जस्तै, 4) : ठूलो शाखा कारक (जस्तै, 4) ले रूखको उचाइ घटाउँछ, छोटो र फराकिलो संरचना सिर्जना गर्दछ। यसले पूर्ण नोडहरूलाई रूख छिटो निर्माण गर्न अनुमति दिन्छ किनकि कम ह्यास अपरेशनहरू आवश्यक पर्दछ। जे होस्, प्रमाणिकरणकर्ताका लागि, यसले प्रत्येक तहमा प्रशोधन गर्नुपर्ने भाइबहिनी ह्यासहरूको संख्या बढाउँछ, जसले ठूलो प्रमाण आकारमा नेतृत्व गर्छ। प्रति प्रमाणिकरण चरणमा थप ह्यासहरूको अर्थ प्रमाणिकरणकर्ताको लागि उच्च कम्प्युटेसनल र ब्यान्डविथ लागतहरू पनि हो, प्रभावकारी रूपमा प्रमाणकर्ताहरूबाट प्रमाणिकरणहरूमा बोझ सार्दै।

कुल डाटा आकार को प्रभाव

Ethereum blockchain बढ्दै जाँदा, प्रत्येक नयाँ लेनदेन, अनुबंध, वा प्रयोगकर्ता अन्तरक्रियाले डेटासेटमा थप्दै जाँदा, Merkle Tree ले पनि विस्तार गर्नुपर्छ। यो वृद्धिले रूखको आकार मात्र बढाउँदैन तर प्रमाण आकार र प्रमाणीकरण समयलाई पनि असर गर्छ।

• मर्कल ट्री कायम राख्न फुल नोडहरूले बढ्दो डेटासेटलाई नियमित रूपमा प्रशोधन र अद्यावधिक गर्नुपर्छ।
• प्रमाणिकरणकर्ताहरूले, बारीमा, डेटासेट बढ्दै जाँदा, थप प्रशोधन समय र ब्यान्डविथ आवश्यक पर्ने लामो र थप जटिल प्रमाणहरू प्रमाणित गर्नुपर्छ।

यो बढ्दो डाटा साइजले पूर्ण नोडहरू र प्रमाणिकरणकर्ताहरूमा माग बढाउँछ, यसले नेटवर्कलाई कुशलतापूर्वक मापन गर्न गाह्रो बनाउँछ। सारांशमा, जबकि Merkle Trees ले दक्षताको डिग्री प्रदान गर्दछ, तिनीहरू Ethereum को लगातार बढ्दो डेटासेटको लागि इष्टतम समाधान हुनबाट कम हुन्छन्। यस कारणले गर्दा, भर्ज चरणको दौडान, Ethereum ले Verkle Trees भनेर चिनिने थप कुशल संरचनाको साथ Merkle Trees लाई प्रतिस्थापन गर्ने लक्ष्य राख्छ। Verkle Trees सँग समान स्तरको सुरक्षा कायम राख्दै साना प्रमाण आकारहरू डेलिभर गर्ने क्षमता छ, प्रमाणीकरण प्रक्रियालाई थप दिगो र Provers र Verifiers दुवैका लागि स्केलेबल बनाउँदै।

किनारा: Ethereum मा क्रान्तिकरण प्रमाणीकरण

Verge Ethereum को रोडम्यापमा एक कोसेढुङ्गाको रूपमा विकसित गरिएको थियो जसको उद्देश्य प्रमाणीकरणमा सुधार गर्ने, ब्लकचेनको विकेन्द्रीकृत संरचनालाई सुदृढ पार्ने र सञ्जाल सुरक्षा बढाउने उद्देश्यले गरिएको थियो। Ethereum सञ्जालको प्राथमिक लक्ष्यहरू मध्ये एक भनेको जो कोहीलाई सजिलैसँग चेन प्रमाणित गर्न प्रमाणिकरण चलाउन सक्षम पार्नु हो, एक संरचना सिर्जना गर्नुहोस् जहाँ सहभागिता केन्द्रीकरण बिना सबैका लागि खुला छ।

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

द मर्जको साथ प्रमाण-अफ-स्टेक सहमति मोडेलमा संक्रमण गरेदेखि, इथरियम मान्यकर्ताहरूसँग दुईवटा प्राथमिक जिम्मेवारीहरू छन्:

1. सहमति सुनिश्चित गर्दै : दुबै सम्भाव्य र निर्धारणवादी सहमति प्रोटोकलहरूको उचित कार्यलाई समर्थन गर्दै र फोर्क-च्वाइस एल्गोरिदम लागू गर्दै।
2. ब्लक शुद्धता जाँच गर्दै : ब्लकमा लेनदेनहरू कार्यान्वयन गरेपछि, नतिजाको राज्य रूखको जरा प्रस्तावकद्वारा घोषित राज्य रूटसँग मेल खान्छ भनेर प्रमाणित गर्दै।

दोस्रो जिम्मेवारी पूरा गर्न, प्रमाणीकरणकर्ताहरूसँग ब्लक अघि राज्यमा पहुँच हुनुपर्छ। यसले तिनीहरूलाई ब्लकको लेनदेनहरू कार्यान्वयन गर्न र त्यसपछिको अवस्था प्राप्त गर्न अनुमति दिन्छ। यद्यपि, यो आवश्यकताले मान्यकर्ताहरूमा भारी बोझ थोपर्छ, किनकि उनीहरूले महत्त्वपूर्ण भण्डारण आवश्यकताहरू ह्यान्डल गर्न आवश्यक छ।

जबकि Ethereum सम्भव हुन डिजाइन गरिएको छ र भण्डारण लागत विश्वव्यापी रूपमा घट्दै गएको छ, मुद्दा लागत को बारे मा कम र मान्यकर्ताहरु को लागी विशेष हार्डवेयर मा निर्भरता को बारे मा अधिक छ। भर्जले यी यन्त्रहरूमा चल्ने भ्यालिडेटरहरूलाई सक्षम पार्दै, मोबाइल फोन, ब्राउजर वालेटहरू, र स्मार्टवाचहरू जस्ता सीमित भण्डारण भएका यन्त्रहरूमा पनि पूर्ण प्रमाणीकरण गर्न सकिने पूर्वाधार सिर्जना गरेर यस चुनौतीलाई पार गर्ने लक्ष्य राखेको छ।

प्रमाणीकरण हासिल गर्ने पहिलो चरण: कुशल राज्य प्रमाणीकरण

Verkle Tree s मा संक्रमण यो प्रक्रिया को एक प्रमुख भाग हो। सुरुमा, भर्जले Ethereum को Merkle Tree को संरचनालाई Verkle Trees ले प्रतिस्थापन गर्नमा ध्यान केन्द्रित गर्यो। Verkle Trees लाई अपनाउनुको प्राथमिक कारण यो हो कि Merkle Trees Ethereum को प्रमाणीकरण को लागी एक महत्वपूर्ण बाधा उत्पन्न गर्दछ। जबकि Merkle Trees र तिनीहरूका प्रमाणहरूले सामान्य परिदृश्यहरूमा कुशलतापूर्वक काम गर्न सक्छन्, तिनीहरूको कार्यसम्पादन सबैभन्दा खराब-केस परिदृश्यहरूमा तीव्र रूपमा घट्छ।

Vitalik को गणना अनुसार, औसत प्रमाण आकार लगभग 4 KB छ, जुन व्यवस्थित लाग्दछ। यद्यपि, सबैभन्दा खराब अवस्थाहरूमा, प्रमाणको आकार 330 MB सम्म बेलुन हुन सक्छ। हो, तपाईंले त्यो सहि पढ्नुभयो—३३० एमबी।

सबैभन्दा खराब अवस्थाहरूमा Ethereum को Merkle Trees को चरम असक्षमता दुई प्राथमिक कारणहरूबाट उत्पन्न हुन्छ:

1. Hexary Trees को प्रयोग : Ethereum ले हाल मर्कल ट्रीज को 16 को शाखा कारक संग प्रयोग गर्दछ। यसको मतलब यो हो कि एकल नोड प्रमाणित गर्न को लागी शाखा मा बाँकी 15 ह्यासहरु प्रदान गर्न आवश्यक छ। इथरियमको अवस्था र शाखाहरूको संख्याको आकारलाई ध्यानमा राख्दै, यसले सबैभन्दा खराब-केस परिदृश्यहरूमा पर्याप्त बोझ सिर्जना गर्दछ।

2. कोडको गैर-मर्केलाइजेशन : रूख संरचनामा अनुबंध कोड समावेश गर्नुको सट्टा, Ethereum ले कोड ह्यास गर्छ र नोडको रूपमा नतिजा मान प्रयोग गर्दछ। ठेक्काको अधिकतम आकार २४ KB हो भन्ने कुरालाई ध्यानमा राख्दै, यो दृष्टिकोणले पूर्ण प्रमाणीकरण प्राप्त गर्नको लागि महत्त्वपूर्ण बोझ थोपर्छ।

प्रमाण आकार शाखा कारक को सीधा समानुपातिक छ। शाखा कारक घटाउँदा प्रमाणको आकार घट्छ। यी समस्याहरूलाई सम्बोधन गर्न र सबैभन्दा खराब-केस परिदृश्यहरू सुधार गर्न, इथरियमले हेक्सरी ट्रीहरूबाट बाइनरी मर्कल ट्रीहरूमा स्विच गर्न र सम्झौता कोडहरू मर्क्लाइज गर्न सुरु गर्न सक्छ। यदि Ethereum मा ब्रान्चिङ कारक 16 बाट 2 मा घटाइयो र अनुबंध कोडहरू पनि मर्कलाइज गरिएको छ भने, अधिकतम प्रमाण आकार 10 MB मा संकुचित हुन सक्छ।

जबकि यो एक महत्वपूर्ण सुधार हो, यो नोट गर्न महत्त्वपूर्ण छ कि यो लागत डाटा को एक टुक्रा प्रमाणीकरण मा लागू हुन्छ। डेटाको धेरै टुक्राहरू पहुँच गर्ने साधारण लेनदेनलाई पनि ठूला प्रमाणहरू चाहिन्छ। प्रति ब्लक लेनदेनको संख्या र Ethereum को लगातार बढ्दो अवस्थालाई ध्यानमा राख्दै, यो समाधान, अझ राम्रो हुँदा, अझै पनि पूर्ण रूपमा सम्भव छैन।

यी कारणहरूका लागि, Ethereum समुदायले मुद्दालाई सम्बोधन गर्न दुई फरक समाधानहरू प्रस्ताव गरेको छ:

1. Verkle रूखहरू
2. STARK प्रमाणहरू + बाइनरी मर्कल रूखहरू

Verkle रूखहरू र भेक्टर प्रतिबद्धताहरू

Verkle Tree s, नामले सुझाव दिएझैं, Merkle Trees जस्तै रूख संरचनाहरू हुन्। यद्यपि, सबैभन्दा महत्त्वपूर्ण भिन्नता प्रमाणिकरण प्रक्रियाहरूमा उनीहरूले प्रस्ताव गर्ने दक्षतामा निहित छ। Merkle Trees मा, यदि एउटा शाखामा 16 टुक्रा डाटा छन् र हामी ती मध्ये एउटा मात्र प्रमाणित गर्न चाहन्छौं भने, अन्य 15 टुक्राहरू कभर गर्ने ह्यास चेन पनि उपलब्ध गराइनुपर्छ। यसले प्रमाणीकरणको कम्प्युटेशनल बोझलाई उल्लेखनीय रूपमा बढाउँछ र ठूलो प्रमाण आकारमा परिणाम दिन्छ।

यसको विपरित, Verkle Trees ले " Eliptic Curve-based Vector Commitments " भनेर चिनिने एक विशेष संरचनाको प्रयोग गर्दछ, अझ विशेष गरी, I nner Product Argument (IPA) मा आधारित भेक्टर प्रतिबद्धता। एक भेक्टर अनिवार्य रूपमा एक विशिष्ट अनुक्रम मा संगठित डाटा तत्वहरूको सूची हो। Ethereum को राज्य एक भेक्टर को रूप मा सोच्न सकिन्छ: एक संरचना जहाँ धेरै डाटा टुक्राहरु एक विशेष क्रममा भण्डारण गरिन्छ, प्रत्येक तत्व महत्वपूर्ण छ। यो राज्यले विभिन्न डेटा कम्पोनेन्टहरू समावेश गर्दछ जस्तै ठेगानाहरू, अनुबंध कोडहरू, र भण्डारण जानकारी, जहाँ यी तत्वहरूको क्रमले पहुँच र प्रमाणीकरणमा महत्त्वपूर्ण भूमिका खेल्छ।

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

Merkle Trees को विपरीत, Verkle Trees ले अण्डाकार वक्र-आधारित भेक्टर प्रतिबद्धताहरू प्रयोग गर्दछ जसले दुई मुख्य फाइदाहरू प्रदान गर्दछ:

• अण्डाकार वक्र-आधारित भेक्टर प्रतिबद्धताहरूले प्रमाणीकरण गरिएको डेटा बाहेक अन्य तत्वहरूको विवरणहरूको आवश्यकतालाई हटाउँछ । Merkle Trees मा 16 को एक शाखा कारक संग, एकल शाखा प्रमाणीकरण गर्न अन्य 15 ह्यासहरू प्रदान गर्न आवश्यक छ। Ethereum को राज्य को विशाल आकार दिईएको छ, जसमा धेरै शाखाहरु सम्मिलित छ, यो एक महत्वपूर्ण अक्षमता सिर्जना गर्दछ। अण्डाकार कर्भ-आधारित भेक्टर प्रतिबद्धताहरू, तथापि, यो जटिलता हटाउनुहोस्, कम डाटा र कम्प्युटेशनल प्रयासको साथ प्रमाणीकरण सक्षम पार्दै।
• बहु-प्रमाणहरू मार्फत, अण्डाकार वक्र-आधारित भेक्टर प्रतिबद्धताहरूद्वारा उत्पन्न गरिएका प्रमाणहरूलाई एकल, स्थिर-आकार प्रमाणमा संकुचित गर्न सकिन्छ। Ethereum को राज्य मात्र ठूलो छैन तर लगातार बढ्दै गएको छ, यसको मतलब मर्कल रूटमा पहुँच गर्न प्रमाणिकरण चाहिने शाखाहरूको संख्या समयसँगै बढ्दै जान्छ। जे होस्, Verkle Trees को साथ, हामी Dankrad Feist को लेख मा विस्तृत विधि को उपयोग गरेर प्रत्येक शाखा को लागी एक एकल स्थिर आकार प्रमाण मा प्रमाण "कम्प्रेस" गर्न सक्छौं। यसले प्रमाणिकरणकर्ताहरूलाई प्रत्येक शाखालाई व्यक्तिगत रूपमा प्रमाणित गर्नुको सट्टा एउटा सानो प्रमाणको साथ सम्पूर्ण रूख प्रमाणित गर्न अनुमति दिन्छ। यसको मतलब यो पनि हो कि Verkle Trees Ethereum को राज्य को विकास द्वारा अप्रभावित छन्।

अण्डाकार कर्भ-आधारित भेक्टर प्रतिबद्धताहरूको यी सुविधाहरूले प्रमाणीकरणको लागि आवश्यक डेटाको मात्रालाई उल्लेखनीय रूपमा घटाउँछ, Verkle Trees लाई सबैभन्दा खराब अवस्थाहरूमा पनि सानो, स्थिर-आकार प्रमाणहरू उत्पादन गर्न अनुमति दिन्छ। यसले डेटा ओभरहेड र प्रमाणिकरण समयलाई कम गर्छ, Ethereum जस्ता ठूला-ठूला नेटवर्कहरूको दक्षतामा सुधार गर्छ। नतिजाको रूपमा, Verkle Trees मा अण्डाकार वक्र-आधारित भेक्टर प्रतिबद्धताहरूको प्रयोगले Ethereum को विस्तारित अवस्थाको अधिक व्यवस्थित र कुशल ह्यान्डलिंग सक्षम बनाउँछ।

सबै आविष्कारहरू जस्तै, Verkle रूखहरू तिनीहरूका सीमितताहरू छन्। तिनीहरूको मुख्य कमजोरीहरू मध्ये एक यो हो कि तिनीहरू अण्डाकार कर्भ क्रिप्टोग्राफीमा भर पर्छन्, जुन क्वान्टम कम्प्युटरहरूको लागि कमजोर छ। क्वान्टम कम्प्युटरहरूमा शास्त्रीय विधिहरू भन्दा धेरै कम्प्युटेशनल शक्ति हुन्छ, जसले अण्डाकार कर्भ-आधारित क्रिप्टोग्राफिक प्रोटोकलहरूमा महत्त्वपूर्ण खतरा खडा गर्छ। क्वान्टम एल्गोरिदमहरूले सम्भावित रूपमा यी क्रिप्टोग्राफिक प्रणालीहरूलाई तोड्न वा कमजोर पार्न सक्छ, जसले Verkle Trees को दीर्घकालीन सुरक्षाको बारेमा चिन्ता बढाउँछ।

यस कारणका लागि, जबकि Verkle Trees ले राज्यविहीनताको लागि आशाजनक समाधान प्रस्ताव गर्दछ, तिनीहरू अन्तिम समाधान होइनन्। यद्यपि, Dankrad Feist जस्ता तथ्याङ्कहरूले Ethereum मा क्वान्टम-प्रतिरोधी क्रिप्टोग्राफी एकीकृत गर्दा सावधानीपूर्वक विचार गर्न आवश्यक छ भन्ने कुरामा जोड दिएका छन्, यो ध्यान दिन लायक छ कि हाल Ethereum मा ब्लबहरूका लागि प्रयोग गरिएका KZG प्रतिबद्धताहरू पनि क्वान्टम-प्रतिरोधी छैनन्। यसरी, Verkle Trees ले एक अन्तरिम समाधानको रूपमा सेवा गर्न सक्छ, नेटवर्कलाई थप बलियो विकल्पहरू विकास गर्न थप समय प्रदान गर्दछ।

STARK प्रमाणहरू + बाइनरी मर्कल रूखहरू

Verkle Trees ले Merkle Trees को तुलनामा साना प्रमाण आकार र कुशल प्रमाणिकरण प्रक्रियाहरू प्रदान गर्दछ, यसले Ethereum को बढ्दो अवस्थाको व्यवस्थापन गर्न सजिलो बनाउँछ। अण्डाकार वक्र-आधारित भेक्टर प्रतिबद्धताहरूको लागि धन्यवाद, ठूला-ठूला प्रमाणहरू उल्लेखनीय रूपमा कम डाटाको साथ उत्पन्न गर्न सकिन्छ। यद्यपि, तिनीहरूको प्रभावशाली फाइदाहरूको बावजुद, क्वान्टम कम्प्युटरहरूमा Verkle Trees को कमजोरीले तिनीहरूलाई अस्थायी समाधान मात्र बनाउँछ।

जबकि Ethereum समुदायले Verkle Trees लाई समय किन्नको लागि छोटो अवधिको उपकरणको रूपमा हेर्छ, दीर्घकालीन फोकस क्वान्टम-प्रतिरोधी समाधानहरूमा संक्रमणमा छ। यही ठाउँमा STARK Proof s र Binary Merkle Trees ले भविष्यको लागि थप बलियो प्रमाणीकरण पूर्वाधार निर्माण गर्न बलियो विकल्प प्रस्तुत गर्दछ।

Ethereum को राज्य प्रमाणिकरण प्रक्रिया मा, मार्कल रूख को शाखा कारक को कम गर्न सकिन्छ (16 देखि 2) बाइनरी Merkle Trees प्रयोग गरेर। यो परिवर्तन प्रमाणको आकार घटाउन र प्रमाणीकरण प्रक्रियाहरूलाई अझ प्रभावकारी बनाउन महत्वपूर्ण कदम हो। यद्यपि, सबैभन्दा खराब अवस्थामा पनि, प्रमाण आकारहरू अझै पनि 10 MB सम्म पुग्न सक्छ, जुन पर्याप्त छ। यी ठूला बाइनरी मर्कल प्रुफहरूलाई केवल १००-३०० kB सम्म कम्प्रेस गरेर, STARK प्रूफहरू खेलमा आउँछन्।

यो अप्टिमाइजेसन विशेष गरी महत्त्वपूर्ण छ जब हल्का क्लाइन्टहरू वा सीमित हार्डवेयर भएका यन्त्रहरूमा अपरेटिङ भ्यालिडेटरहरूको अवरोधहरू विचार गर्दा, विशेष गरी यदि तपाईंले औसत विश्वव्यापी मोबाइल डाउनलोड र अपलोड गति क्रमशः 7.625 MB/s र 1.5 MB/s हो भनेर ध्यानमा राख्नुभयो भने। प्रयोगकर्ताहरूले पूर्ण राज्यमा पहुँच बिना साना, पोर्टेबल प्रमाणहरूको साथ लेनदेनहरू प्रमाणित गर्न सक्छन्, र मान्यकर्ताहरूले सम्पूर्ण राज्य भण्डार नगरी ब्लक प्रमाणीकरण कार्यहरू गर्न सक्छन्।

यो दोहोरो-लाभ दृष्टिकोणले प्रमाणिकरणको गति बढाउँदै, स्केलेबिलिटीको लागि Ethereum को दृष्टिलाई प्रत्यक्ष रूपमा समर्थन गर्ने तीन मुख्य सुधारहरू, मान्यकर्ताहरूको लागि ब्यान्डविथ र भण्डारण आवश्यकताहरू दुवै घटाउँछ।

STARK प्रमाणहरूका लागि प्रमुख चुनौतीहरू

1. प्रोभरहरूको लागि उच्च कम्प्युटेशनल लोड : STARK प्रमाणहरू उत्पन्न गर्ने प्रक्रिया कम्प्युटेशनली गहन छ, विशेष गरी प्रोभर साइडमा, जसले परिचालन लागत बढाउन सक्छ।
2. साना डाटा प्रमाणहरूमा असक्षमता: STARK प्रमाणहरू ठूला डाटासेटहरू ह्यान्डल गर्नमा उत्कृष्ट हुँदा, थोरै मात्रामा डाटा प्रमाणित गर्दा तिनीहरू कम कुशल हुन्छन्, जसले निश्चित परिदृश्यहरूमा उनीहरूको आवेदनलाई बाधा पुर्‍याउन सक्छ। साना चरणहरू वा डेटासेटहरू समावेश गर्ने कार्यक्रमहरूसँग व्यवहार गर्दा, STARKs को तुलनात्मक रूपमा ठूलो प्रमाण आकारले तिनीहरूलाई कम व्यावहारिक वा लागत-प्रभावी बनाउन सक्छ।

क्वान्टम सुरक्षा लागतमा आउँछ: प्रोभर-साइड कम्प्युटेशनल लोड

एक ब्लकको मर्कल प्रमाणले लगभग 330,000 ह्यासहरू समावेश गर्न सक्छ, र सबैभन्दा खराब अवस्थाहरूमा, यो संख्या 660,000 सम्म पुग्न सक्छ। यस्तो अवस्थामा, STARK प्रमाणले प्रति सेकेन्ड लगभग 200,000 ह्यासहरू प्रशोधन गर्न आवश्यक पर्दछ। Poseidon जस्ता zk-मैत्री ह्यास प्रकार्यहरू खेलमा आउँछन्, विशेष गरी यो भार कम गर्न STARK प्रमाणहरूको लागि अनुकूलित।

Poseidon लाई SHA256 र Keccak जस्ता परम्परागत ह्यास एल्गोरिदमहरूको तुलनामा ZK-प्रूफहरूसँग थप सहज रूपमा काम गर्न डिजाइन गरिएको हो। यस अनुकूलताको प्राथमिक कारण परम्परागत ह्यास एल्गोरिदमहरूले कसरी काम गर्छ भन्ने कुरामा निहित छ: तिनीहरूले बाइनरी डाटा (० र १ से) को रूपमा इनपुटहरू प्रशोधन गर्छन्।

अर्कोतर्फ, ZK-प्रूफहरूले प्राइम फिल्डहरू, गणितीय संरचनाहरू जुन मौलिक रूपमा फरक छन्। यो अवस्था बाइनरीमा काम गर्ने कम्प्युटरहरूसँग मिल्दोजुल्दो छ जबकि मानिसहरूले दैनिक जीवनमा दशमलव प्रणाली प्रयोग गर्छन्। बिट-आधारित डाटा ZK-कम्प्याटिबल ढाँचाहरूमा अनुवाद गर्दा महत्त्वपूर्ण कम्प्युटेशनल ओभरहेड समावेश छ। Poseidon ले यस मुद्दालाई मूल रूपमा प्राइम फिल्डहरूमा सञ्चालन गरेर, नाटकीय रूपमा ZK-प्रूफहरूसँग यसको एकीकरणलाई गति दिँदै समाधान गर्छ।

यद्यपि, Poseidon एक अपेक्षाकृत नयाँ ह्यास प्रकार्य भएकोले, यसलाई SHA256 र Keccak जस्ता परम्परागत ह्यास प्रकार्यहरू जस्तै विश्वासको समान स्तर स्थापित गर्न थप व्यापक सुरक्षा विश्लेषण आवश्यक छ। यसका लागि, Poseidon Cryptanalysis Initiative जस्ता पहलहरू, Ethereum Foundation द्वारा सुरु गरिएको, विशेषज्ञहरूलाई Poseidon को सुरक्षाको कडाईका साथ परीक्षण र विश्लेषण गर्न निमन्त्रणा गर्दछ, यसले विरोधी छानबिनको सामना गर्न सक्छ र क्रिप्टोग्राफिक अनुप्रयोगहरूको लागि बलियो मानक बन्न सक्छ। अर्कोतर्फ, पुराना प्रकार्यहरू जस्तै SHA256 र Keccak पहिले नै व्यापक रूपमा परीक्षण गरिसकिएको छ र प्रमाणित सुरक्षा ट्र्याक रेकर्ड छ तर ZK-अनुकूल छैन, जसको परिणाम STARK प्रमाणहरूसँग प्रयोग गर्दा प्रदर्शन घट्छ।

उदाहरणका लागि, यी परम्परागत ह्यास प्रकार्यहरू प्रयोग गरेर STARK प्रमाणहरूले हाल 10,000 देखि 30,000 ह्यासहरू मात्र प्रक्रिया गर्न सक्छ। सौभाग्यवश, STARK टेक्नोलोजीमा भएको प्रगतिले सुझाव दिन्छ कि यो थ्रुपुट चाँडै 100,000 देखि 200,000 ह्यासहरूमा बढ्न सक्छ, उनीहरूको दक्षतामा उल्लेखनीय सुधार।

सानो डाटा प्रमाणित गर्नमा STARKs को अक्षमता

जबकि STARK प्रमाणहरू ठूला डाटासेटहरूको लागि स्केलेबिलिटी र पारदर्शितामा उत्कृष्ट हुन्छन्, तिनीहरूले साना र धेरै डाटा तत्वहरूसँग काम गर्दा सीमितताहरू देखाउँछन्। यी परिदृश्यहरूमा, डेटा प्रमाणित गरिँदैछ प्रायः सानो हुन्छ, तर बहु प्रमाणहरूको आवश्यकता अपरिवर्तित रहन्छ। उदाहरणहरू समावेश छन्:

1. पोस्ट-एए लेनदेन प्रमाणीकरण : खाता एब्स्ट्रेक्शन (एए) संग, वालेटहरूले अनुबंध कोडमा संकेत गर्न सक्छ, नन्स र हस्ताक्षर प्रमाणिकरण जस्ता चरणहरू बाइपास गर्न वा अनुकूलन गर्न सक्छ, जुन हाल Ethereum मा अनिवार्य छ। यद्यपि, प्रमाणीकरणमा यो लचिलोपनले लेनदेनको वैधता प्रमाणित गर्न राज्यमा अनुबंध कोड वा अन्य सम्बन्धित डेटा जाँच गर्न आवश्यक छ।
2. लाइट क्लाइन्ट RPC कलहरू : लाइट क्लाइन्टहरूले नेटवर्कबाट स्टेट डेटा क्वेरी गर्छन् (जस्तै, eth_call अनुरोधको समयमा) पूर्ण नोड चलाउन बिना। यस अवस्थाको शुद्धताको ग्यारेन्टी गर्न, प्रमाणहरूले सोधिएको डाटालाई समर्थन गर्नुपर्छ र यो नेटवर्कको हालको अवस्थासँग मेल खान्छ भनेर पुष्टि गर्नुपर्छ।
3. समावेशी सूचीहरू : साना प्रमाणीकरणकर्ताहरूले शक्तिशाली ब्लक उत्पादकहरूको प्रभावलाई सीमित गर्दै अर्को ब्लकमा लेनदेनहरू समावेश छन् भनी सुनिश्चित गर्न समावेशी सूची संयन्त्रहरू प्रयोग गर्न सक्छन्। यद्यपि, यी लेनदेनहरूको समावेश प्रमाणीकरण गर्न तिनीहरूको शुद्धता प्रमाणित गर्न आवश्यक छ।

त्यस्ता प्रयोगका अवस्थामा, STARK प्रमाणहरूले थोरै फाइदा प्रदान गर्दछ। STARKs, स्केलेबिलिटीलाई जोड दिँदै (उनीहरूको नाममा "S" द्वारा हाइलाइट गरिएको छ), ठूला डाटासेटहरूको लागि राम्रो प्रदर्शन गर्दछ तर साना डाटा परिदृश्यहरूसँग संघर्ष गर्दछ। यसको विपरित, SNARKs , संक्षिप्तताको लागि डिजाइन गरिएको (तिनीहरूको नाममा "S" द्वारा जोड दिए अनुसार), ब्यान्डविथ वा भण्डारण अवरोधहरू भएको वातावरणमा स्पष्ट फाइदाहरू प्रदान गर्दै, प्रमाणको आकार कम गर्नमा ध्यान केन्द्रित गर्दछ।

STARK प्रमाणहरू सामान्यतया 40-50 KB आकारमा हुन्छन्, जुन SNARK प्रमाणहरू भन्दा लगभग 175 गुणा ठूलो हुन्छ, जुन केवल 288 बाइटहरू हुन्। यो आकार भिन्नताले प्रमाणीकरण समय र नेटवर्क लागत दुवै बढाउँछ। STARKs को ठूला प्रमाणहरूको प्राथमिक कारण भनेको स्केलेबिलिटी सुनिश्चित गर्नको लागि पारदर्शिता र बहुपदीय प्रतिबद्धताहरूमा उनीहरूको निर्भरता हो, जसले साना-डेटा परिदृश्यहरूमा प्रदर्शन लागतहरू प्रस्तुत गर्दछ। यस्तो अवस्थामा, मर्कल प्रुफहरू जस्ता छिटो र थप ठाउँ-कुशल विधिहरू अधिक व्यावहारिक हुन सक्छ। मर्कल प्रुफहरूले कम कम्प्युटेशनल लागत र द्रुत अपडेटहरू प्रदान गर्दछ, तिनीहरूलाई यी परिस्थितिहरूको लागि उपयुक्त बनाउँदै।

तालिकामा संक्षिप्त रूपमा, Ethereum सँग छनौट गर्न चार सम्भावित मार्गहरू छन्:

Verkle रूखहरू

1. Verkle Trees ले Ethereum समुदायबाट व्यापक समर्थन प्राप्त गरेको छ, तिनीहरूको विकासलाई सहज बनाउनको लागि दुई-साप्ताहिक बैठकहरू। यस निरन्तर काम र परीक्षणको लागि धन्यवाद, Verkle Trees वर्तमान विकल्पहरू बीच सबैभन्दा परिपक्व र राम्रो-अनुसन्धान समाधानको रूपमा खडा छ। यसबाहेक, तिनीहरूको थप होमोमोर्फिक गुणहरूले राज्य रूट अपडेट गर्न प्रत्येक शाखालाई पुन: गणना गर्ने आवश्यकतालाई हटाउँछ, मर्कल ट्रीजको विपरीत, भेर्कल ट्रीहरूलाई अझ प्रभावकारी विकल्प बनाउँदछ। अन्य समाधानहरूको तुलनामा, Verkle Trees ले "केप इट सिम्पल" वा "सिम्पल इज इज बेस्ट" जस्ता इन्जिनियरिङ सिद्धान्तहरूको पालना गर्दै सरलतामा जोड दिन्छ। यो सादगी Ethereum र सुरक्षा विश्लेषण मा एकीकरण दुवै सुविधा दिन्छ।

2. यद्यपि, Verkle Treesहरू क्वान्टम सुरक्षित छैनन्, जसले तिनीहरूलाई दीर्घकालीन समाधान हुनबाट रोक्छ। यदि Ethereum मा एकीकृत भयो भने, यो प्रविधि भविष्यमा प्रतिस्थापन गर्न आवश्यक छ जब क्वान्टम-प्रतिरोधी समाधान आवश्यक छ। Vitalik पनि Verkle Trees लाई STARK र अन्य प्रविधिहरू परिपक्व हुनका लागि समय किन्नको लागि अस्थायी उपायको रूपमा हेर्छन्। थप रूपमा, Verkle Trees मा प्रयोग गरिएको अण्डाकार वक्र-आधारित भेक्टर प्रतिबद्धताहरूले साधारण ह्यास प्रकार्यहरूको तुलनामा उच्च कम्प्युटेशनल भार लगाउँदछ। ह्यास-आधारित दृष्टिकोणहरूले पूर्ण नोडहरूको लागि छिटो सिङ्क्रोनाइजेसन समय प्रस्ताव गर्न सक्छ। यसबाहेक, धेरै 256-बिट अपरेशनहरूमा निर्भरताले Verkle Trees लाई SNARKs को आधुनिक प्रमाणीकरण प्रणालीहरूमा प्रयोग गरेर प्रमाणित गर्न गाह्रो बनाउँछ, भविष्यका प्रयासहरूलाई प्रमाणको आकार घटाउन जटिल बनाउँछ।

   
   

जे होस्, यो नोट गर्न महत्त्वपूर्ण छ कि Verkle Trees, ह्यासिङमा उनीहरूको गैर-भरोसाको कारण, Merkle Trees भन्दा उल्लेखनीय रूपमा बढी प्रमाणित छन्।

STARKs + Conservative Hash प्रकार्यहरू

1. SHA256 वा BLAKE जस्ता राम्रोसँग स्थापित रूढिवादी ह्यास प्रकार्यहरूसँग STARKs को संयोजनले Ethereum को सुरक्षा पूर्वाधारलाई बलियो बनाउने बलियो समाधान प्रदान गर्दछ। यी ह्यास प्रकार्यहरू दुबै शैक्षिक र व्यावहारिक डोमेनहरूमा व्यापक रूपमा प्रयोग र व्यापक रूपमा परीक्षण गरिएका छन्। थप रूपमा, तिनीहरूको क्वान्टम प्रतिरोधले क्वान्टम कम्प्युटरहरूद्वारा उत्पन्न हुने भविष्यका खतराहरू विरुद्ध इथरियमको लचिलोपन बढाउँछ। सुरक्षा-महत्वपूर्ण परिदृश्यहरूको लागि, यो संयोजनले भरपर्दो आधार प्रदान गर्दछ।

2. यद्यपि, STARK प्रणालीहरूमा रूढिवादी ह्यास प्रकार्यहरूको प्रयोगले महत्त्वपूर्ण प्रदर्शन सीमाहरू प्रस्तुत गर्दछ। यी ह्यास प्रकार्यहरूको कम्प्युटेसनल आवश्यकताहरूले उच्च प्रोभर विलम्बतामा परिणाम दिन्छ, प्रमाण उत्पादनले 10 सेकेन्ड भन्दा बढी लिन्छ। यो एक प्रमुख हानि हो, विशेष गरी ब्लक प्रमाणीकरण जस्ता परिदृश्यहरूमा जुन कम विलम्बताको माग गर्दछ। जबकि बहुआयामी ग्यास प्रस्तावहरू जस्ता प्रयासहरूले खराब-केस र औसत-केस विलम्बतालाई पङ्क्तिबद्ध गर्ने प्रयास गर्छन्, परिणामहरू सीमित छन्। थप रूपमा, यद्यपि ह्यास-आधारित दृष्टिकोणहरूले छिटो सिङ्क्रोनाइजेसन समयलाई सहज बनाउन सक्छ, तिनीहरूको दक्षता STARKs को फराकिलो स्केलेबिलिटी लक्ष्यहरूसँग पङ्क्तिबद्ध नहुन सक्छ। परम्परागत ह्यास प्रकार्यहरूको लामो गणना समयले व्यावहारिक दक्षता घटाउँछ र तिनीहरूको लागूयोग्यता सीमित गर्दछ।

   STARKs + तुलनात्मक रूपमा नयाँ ह्यास प्रकार्यहरू

• नयाँ पुस्ताको STARK-मैत्री ह्यास प्रकार्यहरू (जस्तै, Poseidon) सँग STARKs ले यस प्रविधिको कार्यसम्पादनमा उल्लेखनीय सुधार गर्दछ। यी ह्यास प्रकार्यहरू STARK प्रणालीहरूसँग निर्बाध रूपमा एकीकृत गर्न र प्रोभर विलम्बतालाई तीव्र रूपमा कम गर्न डिजाइन गरिएको हो। परम्परागत ह्यास प्रकार्यहरूको विपरीत, तिनीहरूले प्रमाण उत्पादनलाई 1-2 सेकेन्डमा सक्षम पार्छन्। तिनीहरूको दक्षता र कम कम्प्युटेशनल ओभरहेडले STARKs को स्केलेबिलिटी क्षमता बढाउँछ, तिनीहरूलाई ठूला डेटासेटहरू ह्यान्डल गर्नको लागि अत्यधिक प्रभावकारी बनाउँछ। यो क्षमताले उनीहरूलाई उच्च प्रदर्शन आवश्यक पर्ने अनुप्रयोगहरूको लागि विशेष गरी आकर्षक बनाउँछ।

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

  जालीमा आधारित मर्कल रूखहरू

1. जालीमा आधारित मर्कल ट्रीहरूले एक अग्रेषित-सोच समाधान प्रस्ताव गर्दछ जसले क्वान्टम सुरक्षालाई Verkle Trees को अद्यावधिक दक्षतासँग जोड्दछ। यी संरचनाहरूले Verkle Trees र STARKs दुवैका कमजोरीहरूलाई सम्बोधन गर्छन् र एक आशाजनक दीर्घकालीन विकल्प मानिन्छ। तिनीहरूको जाली-आधारित डिजाइनको साथ, तिनीहरूले क्वान्टम कम्प्युटिङ खतराहरूमा बलियो प्रतिरोध प्रदान गर्दछ, भविष्यमा यसको इकोसिस्टमको प्रूफिंगमा इथरियमको फोकससँग पङ्क्तिबद्ध गर्दै। यसबाहेक, Verkle Trees को अपडेटेबिलिटी फाइदाहरू कायम राखेर, तिनीहरूले दक्षताको त्याग नगरी परिष्कृत सुरक्षा प्रदान गर्ने लक्ष्य राख्छन्।
2. यद्यपि, जालीमा आधारित मर्कल ट्रीहरूमा अनुसन्धान अझै प्रारम्भिक चरणमा छ र धेरै हदसम्म सैद्धान्तिक छ। यसले तिनीहरूको व्यावहारिक कार्यान्वयन र कार्यसम्पादनको बारेमा महत्त्वपूर्ण अनिश्चितता सिर्जना गर्दछ। Ethereum मा यस्तो समाधान एकीकृत गर्न व्यापक अनुसन्धान र विकास आवश्यक हुनेछ, साथै यसको सम्भावित लाभहरू मान्य गर्न कठोर परीक्षण। यी अनिश्चितताहरू र पूर्वाधारात्मक जटिलताहरूले जालीमा आधारित मर्कल ट्रीहरू निकट भविष्यमा Ethereum को लागि सम्भाव्य विकल्प हुन असम्भव बनाउँदछ, सम्भावित रूपमा नेटवर्कको प्रमाणीकरण उद्देश्यहरूतर्फ प्रगतिमा ढिलाइ हुन्छ।

कार्यान्वयनको बारेमा के: EVM कार्यान्वयनको वैधता प्रमाणहरू

हामीले अहिलेसम्म छलफल गरेका सबै कुराहरू अघिल्लो अवस्था भण्डारण गर्न प्रमाणिकरणकर्ताहरूको आवश्यकता हटाउने वरिपरि घुम्छ, जुन तिनीहरूले एक राज्यबाट अर्कोमा ट्रान्जिसन गर्न प्रयोग गर्छन्। लक्ष्य भनेको थप विकेन्द्रीकृत वातावरण सिर्जना गर्नु हो जहाँ मान्यकर्ताहरूले राज्य डाटाको टेराबाइटहरू कायम नगरी आफ्नो कर्तव्यहरू प्रदर्शन गर्न सक्छन्।

हामीले उल्लेख गरेका समाधानहरूको साथमा पनि, मान्यकर्ताहरूले सम्पूर्ण राज्य भण्डारण गर्न आवश्यक पर्दैन, किनकि उनीहरूले ब्लकमा समावेश भएका साक्षीहरू मार्फत कार्यान्वयनको लागि आवश्यक सबै डाटा प्राप्त गर्नेछन्। यद्यपि, अर्को राज्यमा ट्रान्जिसन गर्न — र यसरी ब्लकको शीर्षमा stateRoot प्रमाणित गर्न — मान्यकर्ताहरूले अझै पनि STF आफैं कार्यान्वयन गर्नुपर्छ। यो आवश्यकता, बारीमा, Ethereum को अनुमतिहीन प्रकृति र विकेन्द्रीकरण को लागी अर्को चुनौती खडा गर्दछ।

प्रारम्भमा, भर्जलाई एक माइलस्टोनको रूपमा परिकल्पना गरिएको थियो जुन राज्य प्रमाणीकरणमा सुधार गर्नको लागि मर्कल ट्रीहरूबाट भेर्कल ट्रीहरूमा इथरियमको राज्य रूखलाई परिवर्तन गर्नमा केन्द्रित थियो। तथापि, समय बित्दै जाँदा, यो राज्यको संक्रमण र सहमतिको प्रमाणीकरण बढाउने उद्देश्यले फराकिलो पहलका रूपमा विकसित भएको छ। यस्तो संसारमा जहाँ राज्य, कार्यान्वयन, र सहमतिको त्रिकूट पूर्ण रूपमा प्रमाणित छ, Ethereum प्रमाणिकरणकर्ताहरूले इन्टरनेट जडान भएको कुनै पनि उपकरणमा काम गर्न सक्छन् जसलाई लाइट क्लाइन्टको रूपमा वर्गीकृत गर्न सकिन्छ। यसले Ethereum लाई "साँचो विकेन्द्रीकरण" को दृष्टि प्राप्त गर्न नजिक ल्याउनेछ।

समस्या परिभाषा के हो, फेरि?

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

एक मान्यकर्ता बन्नको लागि उच्च प्रणाली आवश्यकताहरू मुख्य रूपमा यस प्रक्रियालाई कुशलतापूर्वक प्रदर्शन गर्ने आवश्यकताबाट उत्पन्न हुन्छ।

यदि तपाइँ स्मार्ट रेफ्रिजरेटर - हो, रेफ्रिजरेटरलाई पनि - केहि स्थापित सफ्टवेयरको मद्दतले इथरियम प्रमाणिकरणमा परिणत गर्न चाहनुहुन्छ भने, तपाइँ दुई प्रमुख अवरोधहरूको सामना गर्नुहुन्छ:

1. तपाईको फ्रिजमा सम्भवतः पर्याप्त छिटो इन्टरनेट हुने छैन, जसको मतलब हामीले अहिलेसम्म छलफल गरेका राज्य प्रमाणीकरण समाधानहरूको साथमा कार्यान्वयनका लागि आवश्यक डेटा र प्रमाणहरू डाउनलोड गर्न सक्षम हुने छैन।

2. STF का लागि आवश्यक डेटामा पहुँच भए तापनि, योसँग सुरुदेखि अन्त्यसम्म कार्यान्वयन गर्न वा नयाँ राज्य रूख निर्माण गर्न आवश्यक कम्प्युटेसनल शक्ति हुनेछैन।

   
   

लाइट क्लाइन्टहरूले अघिल्लो अवस्था वा अन्तिम ब्लकको सम्पूर्णतामा पहुँच नगरेको कारणले गर्दा हुने समस्याहरू समाधान गर्न, द भर्जले प्रस्तावकर्ताले कार्यान्वयन गर्नु पर्छ र त्यसपछि ब्लकमा प्रमाण संलग्न गर्नुपर्छ। यो प्रमाणले अघिल्लो राज्य मूलबाट अर्को राज्य मूलमा साथै ब्लकको ह्यासमा संक्रमण समावेश गर्दछ। यससँग, लाइट क्लाइन्टहरूले zk-प्रूफको आवश्यकता बिना मात्र तीन 32-बाइट ह्यासहरू प्रयोग गरेर राज्य संक्रमणलाई मान्य गर्न सक्छन्।

यद्यपि, यस प्रमाणले ह्यासहरू मार्फत काम गरेको हुनाले, यसले राज्यको सङ्क्रमणलाई मात्र प्रमाणित गर्छ भन्नु गलत हुनेछ। यसको विपरित, ब्लकमा संलग्न प्रमाणले एकै साथ धेरै चीजहरू मान्य गर्नुपर्दछ:

अघिल्लो ब्लकमा स्टेट रूट = S, अर्को ब्लकमा स्टेट रूट = S + 1, ब्लक ह्यास = H

1. ब्लक आफै मान्य हुनुपर्दछ, र यसको भित्रको राज्य प्रमाण - चाहे Verkle प्रमाण होस् वा STARKs -ले ब्लकसँग भएको डाटालाई सही रूपमा प्रमाणित गर्नुपर्छ। छोटकरीमा: ब्लकको प्रमाणीकरण र साथमा राज्य प्रमाण ।
2. जब STF लाई कार्यान्वयनको लागि आवश्यक डाटा प्रयोग गरी कार्यान्वयन गरिन्छ र H सँग सम्बन्धित ब्लकमा समावेश गरिन्छ, राज्यमा परिवर्तन हुने डाटा सही रूपमा अद्यावधिक हुनुपर्छ। संक्षेपमा: राज्य संक्रमणको प्रमाणीकरण ।
3. जब नयाँ राज्य रूख सही रूपमा अद्यावधिक गरिएको डाटासँग पुन: निर्माण गरिन्छ, यसको मूल मान S + 1 सँग मेल खानुपर्छ। छोटकरीमा: रूख निर्माण प्रक्रियाको प्रमाणीकरण ।

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

यसो भनिएको छ, त्यहाँ तीनवटा फरक मार्गहरू छन् जुन हामीले यस प्रमुख चुनौतीलाई पार गर्न लिन सक्छौं:

1. प्रमाणीकरण र एकत्रीकरणमा समानान्तर : ZK-प्रूफहरूको एक महत्त्वपूर्ण फाइदा भनेको तिनीहरूको एकत्रित हुने क्षमता हो। एकल, कम्प्याक्ट प्रमाणमा बहु प्रमाणहरू संयोजन गर्ने क्षमताले प्रशोधन समयको सन्दर्भमा पर्याप्त दक्षता प्रदान गर्दछ। यसले नेटवर्कमा लोड मात्र कम गर्दैन तर विकेन्द्रीकृत तरिकाले प्रमाणीकरण प्रक्रियाहरूलाई पनि गति दिन्छ। Ethereum जस्तै ठूलो नेटवर्कको लागि, यसले प्रत्येक ब्लकको लागि प्रमाणहरूको थप कुशल उत्पादन सक्षम गर्दछ।

प्रमाण उत्पादनको क्रममा, कार्यान्वयन प्रक्रियाको प्रत्येक सानो टुक्रा (जस्तै, गणना चरणहरू वा डेटा पहुँच) व्यक्तिगत रूपमा प्रमाणित गर्न सकिन्छ, र यी प्रमाणहरू पछि एकल संरचनामा एकत्रित गर्न सकिन्छ। सही मेकानिजमको साथ, यो दृष्टिकोणले ब्लकका प्रमाणहरू धेरै फरक स्रोतहरू (जस्तै, सयौं GPU हरू) द्वारा छिटो र विकेन्द्रीकृत रूपमा उत्पन्न गर्न अनुमति दिन्छ। यसले कार्यसम्पादनलाई बढाउँछ जबकि सहभागीहरूको फराकिलो समूहलाई संलग्न गरेर विकेन्द्रीकरण लक्ष्यमा योगदान पुर्‍याउँछ।

2. अप्टिमाइज्ड प्रूफ प्रणालीहरू प्रयोग गर्दै : नयाँ पुस्ताको प्रमाण प्रणालीहरूमा Ethereum को कम्प्युटेसनल प्रक्रियाहरू छिटो र अधिक कुशल बनाउन सक्ने क्षमता छ। Orion , Binius , र GKR जस्ता उन्नत प्रणालीहरूले सामान्य-उद्देश्यीय गणनाहरूको लागि प्रोभर समयलाई उल्लेखनीय रूपमा घटाउन सक्छ। यी प्रणालीहरूले हालका प्रविधिहरूको सीमितताहरू पार गर्ने लक्ष्य राख्छन्, थोरै स्रोतहरू खपत गर्दा प्रशोधन गति बढाउँदै। स्केलेबिलिटी- र Ethereum जस्तै दक्षता-केन्द्रित नेटवर्कको लागि, त्यस्ता अप्टिमाइजेसनहरूले महत्त्वपूर्ण फाइदा प्रदान गर्दछ। यद्यपि, यी नयाँ प्रणालीहरूको पूर्ण कार्यान्वयनको लागि इकोसिस्टम भित्र व्यापक परीक्षण र अनुकूलता प्रयासहरू आवश्यक पर्दछ।
3. ग्याँस लागत परिवर्तनहरू : ऐतिहासिक रूपमा, Ethereum भर्चुअल मेसिन (EVM) मा सञ्चालनको लागि ग्यास लागत सामान्यतया तिनीहरूको कम्प्युटेसनल लागतहरूको आधारमा निर्धारण गरिएको थियो। यद्यपि, आज, अर्को मेट्रिकले प्रमुखता प्राप्त गरेको छ: prover complexit y। केही अपरेसनहरू प्रमाणित गर्न तुलनात्मक रूपमा सजिलो हुँदा, अरूसँग थप जटिल संरचना छ र प्रमाणित गर्न लामो समय लाग्छ। ग्यास लागत समायोजन कम्प्युटेशनल प्रयासमा मात्र होइन तर अपरेसनहरू प्रमाणित गर्न कठिनाइमा पनि नेटवर्कको सुरक्षा र दक्षता दुवै बढाउनको लागि महत्त्वपूर्ण छ।

यो दृष्टिकोणले खराब-केस र औसत-केस परिदृश्यहरू बीचको खाडललाई कम गर्न सक्छ, अझ लगातार प्रदर्शन सक्षम पार्दै। उदाहरणका लागि, प्रमाणित गर्न गाह्रो हुने अपरेसनहरूमा उच्च ग्यास लागत हुन सक्छ, जबकि प्रमाणित गर्न सजिलो हुनेहरूको लागत कम हुन सक्छ। थप रूपमा, Ethereum को डेटा संरचनाहरू (जस्तै राज्यको रूख वा लेनदेन सूची ) लाई STARK-अनुकूल विकल्पहरूसँग प्रतिस्थापन गर्नाले प्रमाण प्रक्रियाहरूलाई थप गति दिन सक्छ। त्यस्ता परिवर्तनहरूले Ethereum लाई यसको स्केलेबिलिटी र सुरक्षा लक्ष्यहरू प्राप्त गर्न मद्दत गर्दछ जबकि यसको प्रमाणीकरण दृष्टिलाई अझ यथार्थवादी बनाउँदछ।

निष्पादन प्रमाणहरू सक्षम पार्न इथरियमको प्रयासहरूले यसको प्रमाणीकरण लक्ष्यहरू प्राप्त गर्न महत्त्वपूर्ण अवसर प्रतिनिधित्व गर्दछ। यद्यपि, यो लक्ष्यमा पुग्न प्राविधिक आविष्कारहरू मात्र होइन तर समुदाय भित्रको इन्जिनियरिङ प्रयासहरू र महत्वपूर्ण निर्णयहरू पनि चाहिन्छ। लेयर 1 मा कार्यान्वयन प्रक्रियाहरू प्रमाणिकरणयोग्य बनाउन विकेन्द्रीकरणको संरक्षण गर्दै र अवस्थित पूर्वाधारसँग पङ्क्तिबद्ध गर्दै व्यापक प्रयोगकर्ता आधारमा पहुँचयोग्य हुनुको बीचमा सन्तुलन कायम गर्नुपर्छ।

यस सन्तुलनको स्थापनाले कार्यान्वयनको क्रममा अपरेसनहरू प्रमाणित गर्न प्रयोग गरिने विधिहरूको जटिलता बढाउँछ, समानान्तर प्रमाण उत्पादन जस्ता प्रगतिहरूको आवश्यकतालाई हाइलाइट गर्दै। थप रूपमा, यी प्रविधिहरूको पूर्वाधार आवश्यकताहरू (जस्तै, लुकअप तालिकाहरू ) कार्यान्वयन र परिचालन गरिनुपर्छ, जसले अझै पनि पर्याप्त अनुसन्धान र विकासको माग गर्दछ।

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

यद्यपि, लेयर 1 स्तरमा Ethereum को विकेन्द्रीकरण लक्ष्यहरूले त्यस्ता हार्डवेयरहरूलाई अभिनेताहरूको चयन समूहलाई मात्र पहुँचयोग्य हुनबाट रोक्छ। नतिजाको रूपमा, यी समाधानहरू लेयर 2 प्रणालीहरूमा थप व्यापक प्रयोग देख्ने आशा गरिन्छ। यद्यपि, समुदायले प्रमाण उत्पादनको लागि हार्डवेयर आवश्यकताहरूमा पनि सहमतिमा पुग्नै पर्छ।

एउटा प्रमुख डिजाइन प्रश्न उठ्छ: उच्च-अन्त ल्यापटपहरू जस्तै उपभोक्ता-ग्रेड हार्डवेयरमा प्रमाण उत्पादन काम गर्नुपर्छ, वा औद्योगिक पूर्वाधार आवश्यक छ? जवाफले Ethereum को सम्पूर्ण वास्तुकलालाई आकार दिन्छ - लेयर 2 समाधानहरूको लागि आक्रामक अप्टिमाइजेसनलाई अनुमति दिँदै लेयर 1 को लागि थप रूढ़िवादी दृष्टिकोणहरूको माग गर्दै।

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

यद्यपि, त्यस्ता परिवर्तनहरूले हालको प्रणालीसँग पछाडि अनुकूलता तोड्न सक्छ र विकासकर्ताहरूलाई उनीहरूको कोड पुन: लेख्न बाध्य पार्न सक्छ। यस कारणका लागि, कार्यान्वयन प्रमाणहरूको कार्यान्वयन प्राविधिक चुनौती मात्र होइन - यो एक यात्रा हो जुन Ethereum को दीर्घकालीन मानहरूलाई समर्थन गर्न डिजाइन गरिएको हुनुपर्छ।

वास्तविक पूर्ण-प्रमाणीकरणको लागि अन्तिम चरण: सहमति

Ethereum को सहमति संयन्त्रले एक अद्वितीय सन्तुलन स्थापित गर्न प्रयास गर्दछ जसले प्रमाणीकरण लक्ष्यहरू प्राप्त गर्दा विकेन्द्रीकरण र पहुँच सुरक्षित गर्दछ। यस ढाँचामा, सम्भाव्य र निर्धारणवादी सहमति विधिहरूले फरक फाइदा र चुनौतीहरू प्रदान गर्दछ।

सम्भाव्य सहमति एक गपशप संचार मोडेल मा निर्मित छ। यस मोडेलमा, नेटवर्कको प्रतिनिधित्व गर्ने सबै नोडहरूसँग प्रत्यक्ष रूपमा सञ्चार गर्नुको सट्टा, नोडले 64 वा 128 नोडहरूको अनियमित रूपमा चयन गरिएको सेटसँग जानकारी साझा गर्दछ। नोडको चेन चयन यो सीमित जानकारीमा आधारित छ, जसले त्रुटिको सम्भावनालाई परिचय गराउँछ। जे होस्, समयसँगै, ब्लकचेनले प्रगति गर्दै जाँदा, यी चयनहरू ०% त्रुटि दरको साथ सही चेन तर्फ रूपान्तरण हुने अपेक्षा गरिन्छ।

सम्भाव्य संरचनाको एउटा फाइदा यो हो कि प्रत्येक नोडले आफ्नो चेन दृश्यलाई छुट्टै सन्देशको रूपमा प्रसारण गर्दैन, सञ्चार ओभरहेड कम गर्दै। फलस्वरूप, यस्तो संरचनाले तल्लो प्रणाली आवश्यकताहरूसँग धेरै अनुमतिविहीन , विकेन्द्रीकृत नोडहरूसँग काम गर्न सक्छ।

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

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

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

Epochs, जसले 32 स्लटहरू समेट्छ, निर्धारणवादी सहमति प्रस्तुत गर्दछ। यस स्तरमा, प्रमाणीकरणकर्ताहरूले चेनको अर्डरलाई अन्तिम रूप दिन मतदान गर्छन्, निश्चितता सुनिश्चित गर्दै र चेनलाई प्रमाणित गर्न योग्य बनाउँछन्। यद्यपि, यो नियतात्मक संरचनाले युगको स्तरमा ठोस मतहरू मार्फत प्रमाणीकरण प्रदान गर्दछ, यसले सम्भाव्यतावादी संरचनाको कारणले स्वयं युगहरूमा पूर्ण प्रमाणीकरण प्रदान गर्न सक्दैन। यस खाडललाई सम्बोधन गर्न र युगहरू भित्र सम्भाव्य संरचनालाई बलियो बनाउन, इथरियमले सिङ्क समितिको रूपमा चिनिने समाधान विकसित गरेको छ।

अल्टेयरको लाइट क्लाइन्ट प्रोटोकल: सिङ्क समिति

सिंक कमिटी एथेरियमको सम्भावित सहमतिको सीमितताहरू पार गर्न र हल्का ग्राहकहरूको लागि चेनको प्रमाणीकरण सुधार गर्न अल्टेयर अपग्रेडको साथ प्रस्तुत गरिएको संयन्त्र हो। समितिमा 512 अनियमित रूपमा चयन गरिएका मान्यकर्ताहरू छन् जसले 256 युगहरू (~ 27 घण्टा) सेवा गर्छन्। यी मान्यकर्ताहरूले चेनको टाउको प्रतिनिधित्व गर्ने हस्ताक्षर उत्पादन गर्छन्, जसले हल्का ग्राहकहरूलाई ऐतिहासिक चेन डाटा डाउनलोड गर्न आवश्यक बिना नै चेनको वैधता प्रमाणित गर्न अनुमति दिन्छ। समन्वय समितिको कार्यलाई निम्नानुसार संक्षेप गर्न सकिन्छ:

1. समितिको गठन : नेटवर्कमा रहेका सबै मान्यकर्ताहरूबाट ५१२ प्रमाणीकरणकर्ताहरू अनियमित रूपमा चयन गरिएका छन्। यो चयन नियमित रूपमा विकेन्द्रीकरण कायम राख्न र विशेष समूहमा निर्भरता रोक्नको लागि ताजा गरिन्छ।
2. हस्ताक्षर उत्पादन : समितिका सदस्यहरूले एउटा हस्ताक्षर उत्पादन गर्छन् जसले श्रृंखलाको पछिल्लो अवस्थालाई प्रतिनिधित्व गर्दछ। यो हस्ताक्षर सदस्यहरू द्वारा बनाईएको सामूहिक BLS हस्ताक्षर हो र चेनको वैधता प्रमाणित गर्न प्रयोग गरिन्छ।
3. लाइट क्लाइन्ट प्रमाणिकरण : लाइट क्लाइन्टहरूले केवल सिङ्क समितिबाट हस्ताक्षर जाँच गरेर चेनको शुद्धता प्रमाणित गर्न सक्छन्। यसले तिनीहरूलाई विगतको चेन डाटा डाउनलोड नगरी सुरक्षित रूपमा चेन ट्र्याक गर्न अनुमति दिन्छ।

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

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

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

यी सीमितताहरूको कारणले गर्दा, Ethereum इकोसिस्टममा सहमति संयन्त्रलाई पुन: डिजाइन गर्न र छोटो अवधिमा निर्धारणात्मक अन्तिमता प्रदान गर्ने समाधानहरू कार्यान्वयन गर्न निरन्तर प्रयासहरू छन्। Orbit-SSF र 3SF जस्ता प्रस्तावहरूले Ethereum को सहमतिको संरचनालाई ग्राउन्ड अपबाट पुन: आकार दिने लक्ष्य राख्छन्, सम्भावित सहमतिलाई प्रतिस्थापन गर्न थप प्रभावकारी प्रणाली सिर्जना गर्ने। त्यस्ता दृष्टिकोणहरूले चेनको अन्तिम समयलाई छोटो पार्ने मात्र होइन तर अझ प्रभावकारी र प्रमाणित नेटवर्क संरचना प्रदान गर्न पनि खोज्छन्। Ethereum समुदाय सक्रिय रूपमा विकास र भविष्य कार्यान्वयनको लागि यी प्रस्तावहरू तयार गर्न जारी छ।

सहमतिको स्नार्किफिकेशन

Verge ले Ethereum को वर्तमान र भविष्यको सहमति संयन्त्रलाई zk-proof टेक्नोलोजी मार्फत पूर्ण रूपमा प्रतिस्थापन गर्नुको सट्टा थप प्रमाणिकरण योग्य बनाएर बृद्धि गर्ने लक्ष्य राखेको छ। यस दृष्टिकोणले विकेन्द्रीकरण र सुरक्षाको मुख्य सिद्धान्तहरू संरक्षण गर्दै Ethereum को सहमति प्रक्रियाहरूलाई आधुनिकीकरण गर्न खोज्छ। Zk टेक्नोलोजीहरूको साथ चेनको सबै ऐतिहासिक र वर्तमान सहमति प्रक्रियाहरूलाई अनुकूलनले Ethereum को दीर्घकालीन स्केलेबिलिटी र दक्षता लक्ष्यहरू प्राप्त गर्न महत्त्वपूर्ण भूमिका खेल्छ। Ethereum को सहमति तहमा प्रयोग गरिएका आधारभूत कार्यहरू यस प्राविधिक रूपान्तरणमा धेरै महत्त्वपूर्ण छन्। यी सञ्चालनहरू र तिनीहरूले सामना गर्ने चुनौतीहरूलाई नजिकबाट हेरौं।

• ECADDs :
• उद्देश्य : यो अपरेशन वैधकर्ताहरूको सार्वजनिक कुञ्जीहरू जम्मा गर्न प्रयोग गरिन्छ र चेनको शुद्धता र दक्षता सुनिश्चित गर्न महत्त्वपूर्ण छ। BLS हस्ताक्षरहरूको समग्र प्रकृतिको लागि धन्यवाद, धेरै हस्ताक्षरहरू एकल संरचनामा जोड्न सकिन्छ। यसले सञ्चार ओभरहेड कम गर्छ र चेनमा प्रमाणिकरण प्रक्रियाहरूलाई अझ प्रभावकारी बनाउँछ। ठूला प्रमाणिक समूहहरू बीच सिङ्क्रोनाइजेसन सुनिश्चित गर्नाले यो अपरेशनलाई अझ प्रभावकारी बनाउँछ।
• चुनौतीहरू : पहिले उल्लेख गरिएझैं, Ethereum का प्रमाणिकरणकर्ताहरूले युगको समयमा चेनको अर्डरमा मतदान गर्छन्। आज, Ethereum लगभग 1.1 मिलियन मान्यकर्ताहरु संग एक नेटवर्क हो। यदि सबै मान्यकर्ताहरूले एकै साथ आफ्नो मत प्रचार गर्ने प्रयास गरे, यसले नेटवर्कमा महत्त्वपूर्ण तनाव सिर्जना गर्नेछ। यसबाट बच्नको लागि, Ethereum ले मान्यकर्ताहरूलाई एक युगको समयमा स्लट आधारमा मतदान गर्न अनुमति दिन्छ, जहाँ सबै मान्यकर्ताहरूको 1/32 मात्र प्रति स्लट मतदान गर्छन्। यस मेकानिजमले नेटवर्क कम्युनिकेसन ओभरहेड कम गर्छ र सहमतिलाई अझ प्रभावकारी बनाउँछ, आजको प्रमाणीकरणकर्ता गणनालाई हेर्दा, प्रत्येक स्लटमा लगभग 34,000 मान्यकर्ताहरूले मतदान गर्छन्। यसले प्रति स्लट लगभग 34,000 ECADD सञ्चालनहरूमा अनुवाद गर्दछ।
• जोडीहरू :
• उद्देश्य : पेयरिङ अपरेसनहरू BLS हस्ताक्षरहरू प्रमाणित गर्न प्रयोग गरिन्छ, चेनमा epochs को वैधता सुनिश्चित गर्न। यो कार्यले हस्ताक्षरहरूको ब्याच प्रमाणिकरणको लागि अनुमति दिन्छ। यद्यपि, यो zk-अनुकूल छैन, यसले zk-प्रूफ प्रविधि प्रयोग गरेर प्रमाणित गर्न धेरै महँगो बनाउँछ। यसले शून्य-ज्ञान प्रविधिहरूसँग एकीकृत प्रमाणीकरण प्रक्रिया सिर्जना गर्नमा ठूलो चुनौती प्रस्तुत गर्दछ।
• चुनौतिहरू : Ethereum मा जोडा बनाउने कार्यहरू प्रति स्लट अधिकतम 128 प्रमाणीकरणहरू (एकत्रित हस्ताक्षरहरू) मा सीमित छन्, परिणामस्वरूप ECADDs को तुलनामा कम जोडा बनाउने कार्यहरू। यद्यपि, यी सञ्चालनहरूमा zk-मित्रताको अभावले महत्त्वपूर्ण चुनौती खडा गरेको छ। Zk-प्रूफहरूसँग जोडी बनाउने कार्य प्रमाणित गर्नु ECADD अपरेशन प्रमाणित गर्नु भन्दा हजारौं गुणा महँगो छ [२]। यसले शून्य-ज्ञान टेक्नोलोजीहरूको लागि जोड्ने अपरेसनहरूलाई Ethereum को सहमति प्रमाणीकरण प्रक्रियाहरूमा सबैभन्दा ठूलो अवरोधहरू मध्ये एक बनाउँछ।
• SHA256 ह्यास :
• उद्देश्य e: SHA256 ह्यास प्रकार्यहरू चेनको तथ्याङ्क पढ्न र अद्यावधिक गर्न प्रयोग गरिन्छ, चेनको डेटाको अखण्डता सुनिश्चित गर्दै। यद्यपि, तिनीहरूको zk-मित्रताको अभावले zk-प्रूफ-आधारित प्रमाणीकरण प्रक्रियाहरूमा असक्षमताहरू निम्त्याउँछ, Ethereum को भविष्य प्रमाणीकरण लक्ष्यहरूमा प्रमुख अवरोध खडा गर्छ।
• चुनौतीहरू : SHA256 ह्यास प्रकार्यहरू प्राय: पढ्न र चेनको अवस्था अद्यावधिक गर्न प्रयोग गरिन्छ। यद्यपि, तिनीहरूको zk-अमित्रता Ethereum को zk-प्रूफ-आधारित प्रमाणीकरण लक्ष्यहरूसँग संघर्ष गर्दछ। उदाहरण को लागी, दुई epochs को बीचमा, प्रत्येक मान्यकर्ताले Ethereum को Consensus Layer को STF चलाउछ र epoch को समयमा मान्यकर्ता को प्रदर्शन को आधार मा पुरस्कार र जरिवाना संग राज्य अपडेट गर्न को लागी। यो प्रक्रियाले SHA256 ह्यास प्रकार्यहरूमा धेरै निर्भर गर्दछ, zk-proof-आधारित प्रणालीहरूमा महत्त्वपूर्ण रूपमा लागत बढाउँछ। यसले zk टेक्नोलोजीहरूसँग Ethereum को सहमति संयन्त्रलाई पङ्क्तिबद्ध गर्न पर्याप्त बाधा सिर्जना गर्दछ।

हालको सहमति तहमा प्रयोग गरिएका ECADD, Pairing, र SHA256 अपरेसनहरूले Ethereum को प्रमाणीकरण लक्ष्यहरूमा महत्त्वपूर्ण भूमिका खेल्छन्। यद्यपि, तिनीहरूको zk-मित्रताको कमीले यी उद्देश्यहरू प्राप्त गर्ने बाटोमा महत्त्वपूर्ण चुनौतीहरू खडा गर्छ। ECADD अपरेसनहरूले प्रमाणिकरण भोटहरूको उच्च मात्राको कारणले महँगो बोझ सिर्जना गर्दछ, जबकि जोडा बनाउने कार्यहरू, संख्यामा कम भए पनि, zk-प्रूफहरू प्रमाणित गर्न हजारौं गुणा बढी महँगो हुन्छ।

थप रूपमा, SHA256 ह्यास प्रकार्यहरूको zk-अमित्रताले बीकन चेनको राज्य संक्रमणलाई अत्यन्त चुनौतीपूर्ण प्रमाणित गर्दछ। यी मुद्दाहरूले शून्य-ज्ञान प्रविधिहरूसँग इथरियमको अवस्थित पूर्वाधारलाई पङ्क्तिबद्ध गर्न व्यापक रूपान्तरणको आवश्यकतालाई हाइलाइट गर्दछ।

समाधान "बीम चेन": इथरियमको कन्सेन्सस लेयरको पुन: कल्पना गर्दै

नोभेम्बर 12, 2024 मा, डेभकनमा आफ्नो प्रस्तुतीकरणको क्रममा, जस्टिन ड्रेकले इथरियमको सहमति तहलाई मौलिक र व्यापक रूपमा रूपान्तरण गर्ने उद्देश्यले "बीम चेन " नामक प्रस्ताव प्रस्तुत गरे। बीकन चेन लगभग पाँच वर्षको लागि Ethereum को नेटवर्क को कोर मा रहेको छ। यद्यपि, यस अवधिमा, बीकन चेनमा कुनै ठूलो संरचनात्मक परिवर्तनहरू भएका छैनन्। यसको विपरित, प्राविधिक विकासहरू द्रुत गतिमा अगाडि बढेका छन्, बीकन चेनको स्थिर प्रकृतिलाई पार गर्दै।

आफ्नो प्रस्तुतिमा, जस्टिन ड्रेकले जोड दिए कि Ethereum ले यी पाँच वर्षहरूमा MEV समझ , SNARK प्रविधिहरूमा सफलताहरू , र प्राविधिक गल्तीहरूको पूर्वव्यापी जागरूकता जस्ता महत्वपूर्ण क्षेत्रहरूमा महत्त्वपूर्ण पाठहरू सिकेको छ। यी नयाँ सिकाइहरूद्वारा सूचित डिजाइनहरूलाई तीन मुख्य स्तम्भहरूमा वर्गीकृत गरिएको छ: ब्लक उत्पादन , स्ट्याकिंग , र क्रिप्टोग्राफी । निम्न दृश्यहरूले यी डिजाइनहरू र प्रस्तावित रोडम्यापलाई सारांशित गर्दछ:

• हरियो र खैरो बक्सहरूले वृद्धिशील विकासहरू प्रतिनिधित्व गर्दछ जुन प्रत्येक वर्ष एक एक गरी लागू गर्न सकिन्छ। यी प्रकारका सुधारहरू, धेरै अघिल्लो अपग्रेडहरू जस्तै, Ethereum को अवस्थित वास्तुकलालाई अवरोध नगरी चरणबद्ध रूपमा एकीकृत गर्न सकिन्छ।

• अर्कोतर्फ, रातो बाकसहरूले उच्च-सक्रियता , ठूला-ठूला , र आधारभूत परिवर्तनहरूलाई सङ्केत गर्छ जुन सँगै लागू गर्नुपर्छ। ड्रेकका अनुसार, यी परिवर्तनहरूले इथरियमको क्षमता र प्रमाणीकरणलाई एक प्रमुख छलांगमा अगाडि बढाउने लक्ष्य राख्छन्।

  
  

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

जस्टिन ड्रेकको रोडम्याप, उनको डेभकन वार्ताको क्रममा प्रस्तुत गरिएको, बीकन चेनमा SHA256 लाई Poseidon जस्ता zk-मैत्री ह्यास प्रकार्यहरूसँग प्रतिस्थापन गर्ने परिकल्पना गर्दछ। यो प्रस्तावले Ethereum को सहमति तहलाई आधुनिकीकरण गर्ने लक्ष्य राखेको छ, यसलाई अझ प्रमाणित, कुशल, र zk-प्रूफ टेक्नोलोजीहरूसँग पङ्क्तिबद्ध बनाउँदै।

यस सन्दर्भमा, हामी देख्छौं कि Ethereum ले zk-unfriendly ह्यास प्रकार्यहरूसँग मात्र चुनौतीहरूको सामना गर्दैन तर दीर्घकालीन सुरक्षाको लागि यसको सहमति तहमा प्रयोग गरिएका डिजिटल हस्ताक्षरहरूको पुन: मूल्याङ्कन गर्न आवश्यक छ। क्वान्टम कम्प्युटिङको विकासको साथ, डिजिटल हस्ताक्षर एल्गोरिदमहरू जस्तै ECDSA हाल प्रयोगमा छन् महत्त्वपूर्ण खतराहरू सामना गर्न सक्छन्। NIST द्वारा प्रकाशित दिशानिर्देशहरूमा उल्लेख गरिएझैं, 112-बिट सुरक्षा स्तर भएको ECDSA का भेरियन्टहरू 2030 सम्ममा हटाइनेछ र 2035 सम्ममा पूर्ण रूपमा प्रतिबन्धित हुनेछ । यसले भविष्यमा क्वान्टम-सुरक्षित हस्ताक्षरहरू जस्ता थप लचिलो विकल्पहरू तिर Ethereum र समान नेटवर्कहरूको लागि एक संक्रमण आवश्यक छ।

यस बिन्दुमा, ह्यास-आधारित हस्ताक्षरहरू क्वान्टम-प्रतिरोधी समाधानहरूको रूपमा देखा पर्छन् जसले नेटवर्कको सुरक्षा र प्रमाणीकरण लक्ष्यहरूलाई समर्थन गर्न महत्त्वपूर्ण भूमिका खेल्न सक्छ। यस आवश्यकतालाई सम्बोधन गर्नाले बीकन चेनलाई प्रमाणित गर्नको लागि दोस्रो ठूलो अवरोध पनि हटाउँछ: BLS हस्ताक्षरहरू । क्वान्टम सुरक्षा सुनिश्चित गर्नको लागि Ethereum ले लिन सक्ने सबैभन्दा महत्त्वपूर्ण कदमहरू मध्ये एक भनेको पोस्ट-क्वान्टम समाधानहरू जस्तै ह्यास-आधारित हस्ताक्षरहरू र ह्यास-आधारित SNARKs अपनाउने हो।

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

ह्यास-आधारित हस्ताक्षर प्रणालीहरूले मान्यकर्ताहरू र प्रमाणकर्ताहरूलाई पूर्ण रूपमा ह्यास प्रकार्यहरूमा आधारित हस्ताक्षरहरू उत्पन्न गर्न अनुमति दिन्छ, पोस्ट-क्वान्टम सुरक्षा सुनिश्चित गर्दै नेटवर्कमा उच्च स्तरको प्रमाणिकरण प्रदान गर्दछ — विशेष गरी यदि SNARK-मैत्री ह्यास प्रकार्य प्रयोग गरिन्छ। यो दृष्टिकोणले नेटवर्कको सुरक्षा मात्र बढाउँदैन तर Ethereum को दीर्घकालीन सुरक्षा पूर्वाधारलाई अझ बलियो र भविष्य-प्रमाण पनि बनाउँछ।

यो प्रणाली ह्यास-आधारित हस्ताक्षरहरू र ह्यास-आधारित SNARKs (STARK-जस्तै प्रमाणहरू) को संयोजनमा समग्र हस्ताक्षर योजनाहरू सिर्जना गर्न निर्भर गर्दछ। एग्रीगेटेबल हस्ताक्षरहरूले हजारौं हस्ताक्षरहरूलाई एकल संरचनामा कम्प्रेस गर्छ, यसलाई प्रमाणको केही सय किलोबाइटमा घटाउँछ। यो कम्प्रेसनले नेटवर्कमा डाटा लोडलाई महत्त्वपूर्ण रूपमा घटाउँछ जबकि प्रमाणीकरण प्रक्रियाहरूलाई धेरै गति दिन्छ। उदाहरणका लागि, Ethereum मा एकल स्लटको लागि उत्पादन गरिएका हजारौं प्रमाणिक हस्ताक्षरहरू एकल जम्मा हस्ताक्षरद्वारा प्रतिनिधित्व गर्न सकिन्छ, भण्डारण ठाउँ र कम्प्युटेसनल शक्ति दुवै बचत गर्दै।

यद्यपि, यस योजनाको सबैभन्दा उल्लेखनीय विशेषता भनेको यसको असीम पुनरावर्ती एकत्रीकरण हो। त्यो हो, हस्ताक्षरको एक समूहलाई अर्को समूह अन्तर्गत जोड्न सकिन्छ, र यो प्रक्रिया चेनभर जारी रहन सक्छ। यस संयन्त्रको साथ र भविष्यको प्राविधिक विकासलाई विचार गर्दै, यो भन्नु उचित छ कि यसले BLS सँग हालै प्राप्त गर्न नसकिने सम्भावनाहरूको ढोका खोल्छ।

निष्कर्ष

प्रमाणीकरणको लागि इथरियमको मार्गले ब्लकचेन टेक्नोलोजीमा आधारभूत परिवर्तनलाई प्रतिनिधित्व गर्दछ। भर्ज पहलले राज्य प्रमाणीकरणका लागि Verkle Trees मार्फत मूल असक्षमताहरूलाई सम्बोधन गर्दछ र स्केलेबल ट्रान्जिसनहरूको लागि STARK प्रमाणहरू।

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

NIST ले 2035 सम्म वर्तमान अण्डाकार कर्भ क्रिप्टोग्राफीलाई चरणबद्ध गर्ने योजनाको साथ, Ethereum ले ह्यास-आधारित हस्ताक्षर र Poseidon जस्ता क्वान्टम-प्रतिरोधी समाधानहरू अपनाउनुपर्छ। यी समाधानहरूले तिनीहरूको आफ्नै दक्षता ट्रेड-अफहरू प्रस्तुत गर्दछ।

Ethereum को रोडम्यापमा STARKs को प्रयोगले स्केलेबिलिटी र प्रमाणीकरणलाई थप जोड दिन्छ। जब तिनीहरू पारदर्शी र क्वान्टम-प्रतिरोधी प्रमाणहरू प्रदान गर्नमा उत्कृष्ट हुन्छन्, तिनीहरूको एकीकरणले प्रोभर-साइड कम्प्युटेशनल लागत र साना-डेटा असक्षमताहरूसँग सम्बन्धित चुनौतीहरू प्रस्तुत गर्दछ। यी बाधाहरूलाई सम्बोधन गर्न आवश्यक छ राज्यविहीनता र कुशल ब्लक प्रमाणिकरणको Ethereum को दृष्टिकोण पूर्ण रूपमा महसुस गर्न, बढ्दो मागको सामनामा नेटवर्क बलियो रहेको सुनिश्चित गर्दै।

यी प्रगतिहरूको बावजुद, मुख्य चुनौतीहरू छन्। Ethereum ले zk-मित्रता , सहमति मापन योग्यता, र क्वान्टम-प्रतिरोधी क्रिप्टोग्राफी एकीकृत गर्ने जटिलताहरू नेभिगेट गर्नुपर्छ। यसबाहेक, अवस्थित पूर्वाधारको पछाडि अनुकूलताले व्यावहारिक बाधाहरू खडा गर्छ जसलाई विकासकर्ताहरू र प्रयोगकर्ताहरूलाई समान रूपमा अवरोधहरू रोक्नको लागि सावधान इन्जिनियरिङ समाधानहरू आवश्यक पर्दछ।

Ethereum लाई अलग गर्ने कुरा भनेको यसको प्राविधिक आविष्कार मात्र होइन तर ब्लकचेनमा भएका केही कठिन समस्याहरू समाधान गर्न यसको पुनरावृत्ति दृष्टिकोण हो। अगाडिको बाटो — चाहे Beam Chain , Verkle Trees , वा STARK प्रमाणहरू जस्ता प्रविधिहरू मार्फत होस् — विकासकर्ताहरू, अनुसन्धानकर्ताहरू र बृहत् समुदायको सहयोगी प्रयासमा निर्भर हुन्छ। यी प्रगतिहरू रातारात पूर्णता हासिल गर्ने बारे होइन तर पारदर्शी , विकेन्द्रीकृत , र प्रमाणिकरणयोग्य इन्टरनेटको लागि आधार निर्माण गर्ने बारे हो।

Ethereum को विकास Web3 युग को आकार मा एक महत्वपूर्ण खेलाडी को रूप मा आफ्नो भूमिका लाई रेखांकित गर्दछ। व्यावहारिक समाधानहरूको साथ आजका चुनौतीहरूको सामना गरेर, Ethereum भविष्यको नजिक जान्छ जहाँ प्रमाणीकरण , क्वान्टम प्रतिरोध , र स्केलेबिलिटी मानक बन्छ, अपवाद होइन।