Trending News

BTC
$16,949.00
-0.94
ETH
$1,274.82
-0.7
LTC
$76.41
-0.83
DASH
$45.02
+1.54
XMR
$144.33
+0.92
NXT
$0.00
-6.45
ETC
$19.48
-2.21

सबूत का बोझ: कोड मर्कलाइज़ेशन

0


स्टेटलेस एथेरियम पहल के बारे में एक नोट:

2020 की दूसरी छमाही में अनुसंधान गतिविधि (स्पष्ट रूप से) धीमी हो गई है क्योंकि सभी योगदानकर्ताओं ने अजीब समयरेखा पर जीवन को समायोजित कर लिया है। लेकिन जैसे-जैसे पारिस्थितिकी तंत्र धीरे-धीरे Serenity और Eth1/Eth2 विलय के करीब जाता है, स्टेटलेस एथेरियम का काम तेजी से प्रासंगिक और प्रभावशाली होता जाएगा। आने वाले हफ्तों में साल के अंत में अधिक महत्वपूर्ण स्टेटलेस एथेरियम पूर्वव्यापी की अपेक्षा करें।

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

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

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

बाइटकोड क्या है?

अनुबंध बायटेकोड को विभाजित करते समय विचार करने के लिए कुछ ट्रेड-ऑफ हैं। अंततः हमें जो प्रश्न पूछने की आवश्यकता होगी वह यह है कि “कोड के टुकड़े कितने बड़े होंगे?” – लेकिन अभी के लिए, आइए एक बहुत ही सरल स्मार्ट अनुबंध में कुछ वास्तविक बायटेकोड देखें, बस यह समझने के लिए कि यह क्या है:

pragma solidity >=0.4.22 <0.7.0;

contract Storage {

    uint256 number;

    function store(uint256 num) public {
        number = num;
    }

    function retrieve() public view returns (uint256){
        return number;
    }
}

जब इस साधारण भंडारण अनुबंध को संकलित किया जाता है, तो यह मशीन कोड में बदल जाता है जिसका मतलब ईवीएम के ‘अंदर’ चलाना है। यहां, आप ऊपर दिखाए गए समान सरल भंडारण अनुबंध देख सकते हैं, लेकिन अलग-अलग ईवीएम निर्देशों (ऑपकोड) का अनुपालन करते हैं:

PUSH1 0x80 PUSH1 0x40 MSTORE CALLVALUE DUP1 ISZERO PUSH1 0xF JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH1 0x4 CALLDATASIZE LT PUSH1 0x32 JUMPI PUSH1 0x0 CALLDATALOAD PUSH1 0xE0 SHR DUP1 PUSH4 0x2E64CEC1 EQ PUSH1 0x37 JUMPI DUP1 PUSH4 0x6057361D EQ PUSH1 0x53 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST PUSH1 0x3D PUSH1 0x7E JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x7C PUSH1 0x4 DUP1 CALLDATASIZE SUB PUSH1 0x20 DUP2 LT ISZERO PUSH1 0x67 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST DUP2 ADD SWAP1 DUP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 SWAP3 SWAP2 SWAP1 POP POP POP PUSH1 0x87 JUMP JUMPDEST STOP JUMPDEST PUSH1 0x0 DUP1 SLOAD SWAP1 POP SWAP1 JUMP JUMPDEST DUP1 PUSH1 0x0 DUP2 SWAP1 SSTORE POP POP JUMP INVALID LOG2 PUSH5 0x6970667358 0x22 SLT KECCAK256 DUP13 PUSH7 0x1368BFFE1FF61A 0x29 0x4C CALLER 0x1F 0x5C DUP8 PUSH18 0xA3F10C9539C716CF2DF6E04FC192E3906473 PUSH16 0x6C634300060600330000000000000000

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

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

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

PUSH1 0x0 DUP1 SLOAD SWAP1 POP SWAP1 JUMP,

JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN

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

कोड के गवाह

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

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

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

कोड मर्कलाइज़ेशन का उद्देश्य कोड के उस विशाल हिस्से को विभाजित करना और क्षेत्र को बदलना है कोडहाश एक एथेरियम खाते में एक और मर्कल ट्री की जड़ के साथ, जिसे उपयुक्त नाम दिया गया है कोडट्री.

हैश में इसके वजन के लायक

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

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

ERC20 उदाहरण में, कॉल करना स्थानांतरण करना() फ़ंक्शन पूरे स्मार्ट अनुबंध के आधे से थोड़ा कम का उपयोग करता है:

XXX.XXXXXXXXXXXXXXXXXX..........................................
.....................XXXXXX.....................................
............XXXXXXXXXXXX........................................
........................XXX.................................XX..
......................................................XXXXXXXXXX
XXXXXXXXXXXXXXXXXX...............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX..................................
.......................................................XXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXX..................................X
XXXXXXXX........................................................
....

यदि हम उस कोड को 64 बाइट्स में विभाजित करना चाहते हैं, तो 41 में से केवल 19 चंक्स को स्टेटलेस निष्पादित करने की आवश्यकता होगी स्थानांतरण करना() लेन-देन, बाकी आवश्यक डेटा एक गवाह से आने के साथ।

|XXX.XXXXXXXXXXXX|XXXXXX..........|................|................
|................|.....XXXXXX.....|................|................
|............XXXX|XXXXXXXX........|................|................
|................|........XXX.....|................|............XX..
|................|................|................|......XXXXXXXXXX
|XXXXXXXXXXXXXXXX|XX..............|.XXXXXXXXXXXXXXX|XXXXXXXXXXXXXXXX
|XXXXXXXXXXXXXXXX|XXXXXXXXXXXXXX..|................|................
|................|................|................|.......XXXXXXXXX
|XXXXXXXXXXXXXXXX|XXXXXXXXXXXXX...|................|...............X
|XXXXXXXX........|................|................|................
|....

इसकी तुलना 32 बाइट चंकिंग स्कीम में 81 में से 31 विखंडू से करें:

|XXX.XXXX|XXXXXXXX|XXXXXX..|........|........|........|........|........
|........|........|.....XXX|XXX.....|........|........|........|........
|........|....XXXX|XXXXXXXX|........|........|........|........|........
|........|........|........|XXX.....|........|........|........|....XX..
|........|........|........|........|........|........|......XX|XXXXXXXX
|XXXXXXXX|XXXXXXXX|XX......|........|.XXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX
|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXX..|........|........|........|........
|........|........|........|........|........|........|.......X|XXXXXXXX
|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXX...|........|........|........|.......X
|XXXXXXXX|........|........|........|........|........|........|........
|....

सतह पर ऐसा लगता है कि छोटे टुकड़े बड़े की तुलना में अधिक कुशल होते हैं, क्योंकि अधिकतर-खाली टुकड़े कम बार-बार होते हैं। लेकिन यहां हमें यह याद रखने की जरूरत है कि अप्रयुक्त कोड की लागत भी होती है: प्रत्येक गैर-निष्पादित कोड खंड को हैश द्वारा बदल दिया जाता है निर्धारित माप. छोटे कोड विखंडू का मतलब अप्रयुक्त कोड के लिए हैश की अधिक संख्या है, और वे हैश 32 बाइट्स (या 8 बाइट्स जितना छोटा) जितना बड़ा हो सकता है। आप इस बिंदु पर “होल’ अप का दावा कर सकते हैं! यदि कोड भाग का हैश 32 बाइट्स का मानक आकार है, तो यह 32 बाइट्स कोड को 32 बाइट्स हैश के साथ बदलने में कैसे मदद करेगा!”।

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

हमें अतिरिक्त डेटा एकत्र करना चाहिए

जिस निष्कर्ष पर हम निर्माण कर रहे हैं, वह एक एंटीक्लाइमेक्स है: कोड मर्कलाइज़ेशन के लिए कोई सैद्धांतिक रूप से ‘इष्टतम’ योजना नहीं है। डिज़ाइन विकल्प जैसे कोड चंक्स और हैश के आकार को ठीक करना ‘वास्तविक दुनिया’ के बारे में एकत्रित आंकड़ों पर निर्भर. प्रत्येक स्मार्ट अनुबंध अलग-अलग रूप से विलीन हो जाएगा, इसलिए शोधकर्ताओं पर उस प्रारूप को चुनने का बोझ है जो देखे गए मेननेट गतिविधि के लिए सबसे बड़ा दक्षता लाभ प्रदान करता है। इसका सबसे सही मतलब क्या है?

भूमि के ऊपर

एक चीज जो संकेत कर सकती है कि कोड मर्कलाइज़ेशन योजना कितनी कुशल है मर्कलाइज़ेशन ओवरहेडजो इस सवाल का जवाब देता है कि “इस गवाह में निष्पादित कोड से परे कितनी अतिरिक्त जानकारी शामिल हो रही है?”

हमारे पास पहले से ही है कुछ आशाजनक परिणामका उपयोग करके एकत्र किया गया एक उद्देश्य से निर्मित उपकरण कॉन्सेंसिस की टीमएक्स रिसर्च टीम के होरासियो मिजेल द्वारा विकसित किया गया है, जो ओवरहेड्स को 25% जितना छोटा दिखाता है – बिल्कुल भी बुरा नहीं!

संक्षेप में, डेटा से पता चलता है कि बड़े और छोटे चंक आकार बड़े लोगों की तुलना में अधिक कुशल होते हैं, खासकर यदि छोटे हैश (8-बाइट्स) का उपयोग किया जाता है। लेकिन ये शुरुआती संख्याएं किसी भी तरह से व्यापक नहीं हैं, क्योंकि ये केवल हाल के लगभग 100 ब्लॉकों का प्रतिनिधित्व करती हैं। यदि आप इसे पढ़ रहे हैं और अधिक पर्याप्त कोड मर्कलाइज़ेशन डेटा एकत्र करके स्टेटलेस एथेरियम पहल में योगदान करने में रुचि रखते हैं, तो ethresear.ch फ़ोरम, या #code-merkleization चैनल पर Eth1x/2 शोध विवाद पर अपना परिचय दें!

और हमेशा की तरह, यदि आपके पास ट्विटर पर “द 1.X फाइल्स” और स्टेटलेस एथेरियम, डीएम या @gichiba से संबंधित प्रश्न, प्रतिक्रिया या अनुरोध हैं।



Source link

Leave A Reply

Your email address will not be published.

Shares