सॉलिडिटी में एक स्मार्ट कॉन्ट्रैक्ट की लगातार मेमोरी के लिए सरणियों का अधिक कुशल लेखन

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

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

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

भोला दृष्टिकोण

ठीक है, चलो हमारे डेटा को बचाने की कोशिश करते हैं। उनमें से एक महत्वपूर्ण हिस्सा 8-बिट अहस्ताक्षरित पूर्णांक है, इसलिए हम उनके सरणी को अनुबंध में स्थानांतरित करेंगे, और उन्हें केवल-पढ़ने के लिए मेमोरी में लिखने का प्रयास करें:

uint8[] m_test; function test(uint8[] data) public { m_test = data; } 

हे भगवान! यह फ़ंक्शन गैस खाता है, जैसे कि स्वयं में नहीं। 100 मूल्यों को बचाने के प्रयास में हमें 814033 गैस, 8100 गैस प्रति बाइट खर्च हुई!

साँस छोड़ें और सिद्धांत पर वापस जाएँ। इथेरियम ब्लॉकचेन पर डेटा संग्रहीत करने की न्यूनतम लागत (गैस में) क्या है? यह याद रखना चाहिए कि डेटा 32 बाइट्स के ब्लॉक में संग्रहीत है। ईवीएम एक बार में केवल एक पूरे ब्लॉक को पढ़ या लिख ​​सकता है, इसलिए आदर्श रूप से, लिखे जाने वाले डेटा को यथासंभव कुशलता से पैक किया जाना चाहिए ताकि एक एकल लेखन कमांड तुरंत और अधिक बचत करे। क्योंकि यह एक ही रिकॉर्डिंग कमांड - SSTORE - अकेले की लागत 20,000 गैस है (यदि हम एक मेमोरी सेल में लिखते हैं जिसे हमने पहले नहीं लिखा है)। तो हमारे सैद्धांतिक न्यूनतम, अन्य सभी खर्चों को नजरअंदाज करते हुए, प्रति बाइट लगभग 625 गैस है। 8100 से दूर जो हमें ऊपर के उदाहरण में मिला है! अब गहरी खुदाई करने और यह पता लगाने का समय है कि हमारी गैस कौन खा रहा है, और इसे कैसे रोका जाए।

हमारा पहला आवेग हमारी लोन लाइन (m_test = data) से सॉलिडिटी कंपाइलर द्वारा उत्पन्न कोड को देखने के लिए होना चाहिए, क्योंकि देखने के लिए और कुछ नहीं है। यह एक अच्छा, सही आवेग है जो हमें एक भयानक तथ्य से परिचित कराएगा - इस स्थान पर संकलक ने कुछ प्राचीन भयावहता उत्पन्न की जिसे आप पहली नजर में समझ नहीं पाएंगे! लिस्टिंग पर एक नज़र डालते हुए, हम देखते हैं कि न केवल SSTORE (जो अपेक्षित है), बल्कि SLOAD (रीड-ओनली मेमोरी से लोड हो रहा है) और यहां तक ​​कि EXP (एक्सपेंसेशन) भी है! कुल मिलाकर, यह डेटा रिकॉर्ड करने का एक बहुत ही महंगा तरीका है। और सबसे बुरा, यह काफी स्पष्ट हो जाता है कि SSTORE को बहुत बार कहा जाता है। यहाँ क्या हो रहा है?

कुछ बातें। यह पता चला है कि 8-बिट पूर्णांक को संग्रहीत करना लगभग सबसे खराब चीज है जिसे आप ईवीएम / सॉलिडिटी (लेख, एक लिंक जिसे मैंने शुरुआत में उद्धृत किया था, इस बारे में बात करता है) के साथ कर सकता है। हम हर मोड़ पर उत्पादकता (जिसका अर्थ है कि हम अधिक गैस का भुगतान करते हैं) खो देते हैं। सबसे पहले, जब हम अपने फ़ंक्शन के इनपुट के लिए 8-बिट मानों की एक सरणी पास करते हैं, तो उनमें से प्रत्येक 256 बिट्स तक फैलता है। यही है, केवल लेनदेन डेटा के आकार से हम पहले से ही 32 बार खो देते हैं! प्यारा! हालांकि, एक चौकस पाठक ध्यान देगा कि संग्रहीत बाइट के लिए लागत, फिर भी, सैद्धांतिक न्यूनतम की तुलना में केवल 13 गुना अधिक है, और 32 नहीं है, जिसका मतलब है कि अनुबंध को स्थायी स्मृति में सहेजते समय, सब कुछ इतना बुरा नहीं है। यहां बात यह है: जब बचत होती है, तो यह अभी भी डेटा को पैक करता है, और अनुबंध की स्थायी मेमोरी में हमारे 8-बिट नंबर को सबसे कुशल तरीके से संग्रहीत किया जाएगा, प्रत्येक मेमोरी ब्लॉक में 32 टुकड़े। यह सवाल भी पैदा करता है, लेकिन "256-बिट" अनपैक्ड नंबरों का रूपांतरण कैसे होता है जो फ़ंक्शन के इनपुट में एक पैक रूप में हमारे पास आया था? जवाब "सबसे बेवकूफ तरीका है जिसकी मैं कल्पना कर सकता हूं।"

यदि हम वह सब कुछ लिखते हैं जो एक सरलीकृत रूप में होता है, तो हमारी एकाकी रेखा एक भयानक चक्र में बदल जाती है:

 for(uint i = 0; i < data.length; ++i) { //      ,    256-bit  8-bit uint8 from_value = uint8(data[i]); //  32-     -        ,     uint256 to_value = get_storage_data_at_offset(m_test, i); //        (    2  ) add_byte_to_value(to_value, i % 32, from_value); //  32-      set_storage_data_at_offset(m_test, i, to_value); } 

जिस तरह से यह कोड दिखता है, वह अनुकूलन को चालू या बंद करने से लगभग अप्रभावित है (कम से कम सॉलिडिटी कंपाइलर संस्करण 0.4.24 में), और जैसा कि आप देख सकते हैं, यह SSTORE (set_storage_data_at_offset के भाग के रूप में) को आवश्यक से 32 गुना अधिक बार कहता है (प्रत्येक 8-बिट संख्या के लिए एक बार, और 32 ऐसी संख्याओं के लिए एक बार नहीं)। जो चीज़ हमें पूर्ण फ़िस्को से बचाती है, वह यह है कि एक ही सेल में री-रिकॉर्डिंग की लागत 20,000 नहीं, बल्कि 5,000 गैस है। तो हर 32 बाइट्स की लागत हमें 20,000 + 5,000 * 31 = 125,000 गैस, या लगभग 4,000 गैस प्रति बाइट। बाकी जो मूल्य हमने ऊपर देखा, वह मेमोरी (एक सस्ता ऑपरेशन नहीं है) और अन्य गणना के कार्यों में उपरोक्त कोड में छिपा हुआ है (और उनमें से कई हैं)।

खैर, हम संकलक के साथ कुछ भी नहीं कर सकते हैं, इसलिए हम एक बटन की तलाश करेंगे । यह केवल यह निष्कर्ष निकालता है कि इस तरह से 8-बिट संख्या के अनुबंध सरणियों में स्थानांतरण और स्टोर करना आवश्यक नहीं है।

8-बिट संख्या के लिए सरल समाधान

और क्या आवश्यक है? और इसलिए:

 bytes m_test; function test(bytes data) public { m_test = data; } 

हम सभी प्रकार के बाइट्स में काम करते हैं। इस दृष्टिकोण के साथ, 100 मूल्यों को बचाने पर 129914 गैस खर्च होगी - प्रति बाइट केवल 1300 गैस, uint8 का उपयोग करने की तुलना में 6 गुना बेहतर होगा!] इसके लिए लागत कुछ असुविधा होगी - प्रकार बाइट्स के एक सरणी के तत्व प्रकार बाइट्स 1 के हैं, जो स्वचालित रूप से किसी भी सामान्य पूर्णांक प्रकार में परिवर्तित नहीं होते हैं, इसलिए आपको स्पष्ट प्रकार के रूपांतरण को सही स्थानों पर रखना होगा। बहुत अच्छा नहीं है, लेकिन लाभ रिकॉर्डिंग की लागत का 6 गुना है, मुझे लगता है कि यह इसके लायक है! और, हाँ, हम इस डेटा के साथ काम करने के दौरान थोड़ा खो देंगे, जब पढ़ना, प्रत्येक संख्या को 256-बिट के रूप में संग्रहीत करने की तुलना में, लेकिन यहां पैमाने पर बात शुरू होती है: एक हजार या दो 8-बिट संख्या को पैक रूप में सहेजने से लाभ हो सकता है , कार्य के आधार पर, बाद में उन्हें पढ़ते समय होने वाली हानियों को दूर करता है।

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

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

अधिक सामान्य समाधान

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

शुरू करने के लिए, आइए इस बारे में बात करें कि सॉलिडिटी स्मृति में एक सरणी कैसे संग्रहीत करती है। Arrays एक अवधारणा है जो केवल सॉलिडिटी के ढांचे के भीतर मौजूद है, ईवीएम उनके बारे में कुछ भी नहीं जानता है, लेकिन बस 2 ^ 256 32-बाइट ब्लॉकों के एक आभासी सरणी को संग्रहीत करता है। यह स्पष्ट है कि खाली ब्लॉकों को संग्रहीत नहीं किया जाता है, लेकिन वास्तव में, हमारे पास गैर-रिक्त ब्लॉकों की एक तालिका है, जिनमें से कुंजी 256-बिट संख्या है। और यह ठीक यही संख्या है कि EVM SSTORE और SLOAD कमांड स्वीकार करते हैं (यह प्रलेखन से पूरी तरह स्पष्ट नहीं है)।

सरणियों को संग्रहीत करने के लिए, सॉलिडिटी इस तरह की एक मुश्किल काम करता है : सबसे पहले, अनुबंध के सदस्यों (या संरचनाओं के प्लेसमेंट के सामान्य क्रम में "मेन" ब्लॉक सरणी को लगातार मेमोरी में कहीं न कहीं के लिए आवंटित किया जाता है, जैसे कि यह एक अलग गीत है) नियमित 256-बिट संख्या। यह सुनिश्चित करता है कि सरणी अन्य संग्रहीत चर की परवाह किए बिना एक पूर्ण ब्लॉक प्राप्त करता है। यह ब्लॉक सरणी की लंबाई को संग्रहीत करता है। लेकिन चूंकि यह पहले से ज्ञात नहीं है, और बदल सकता है (हम यहां गतिशील सरणियों के बारे में बात कर रहे हैं), सॉलिडिटी के लेखकों को यह पता लगाने की आवश्यकता है कि सरणी के डेटा को कहां रखा जाए ताकि वे गलती से किसी अन्य सरणी के डेटा के साथ प्रतिच्छेद न करें। सख्ती से बोलना, यह एक अघुलनशील कार्य है: यदि आप 2 ^ 128 लंबे समय तक दो सरणियों का निर्माण करते हैं, तो उन्हें यह सुनिश्चित करने की गारंटी दी जाती है कि आप उन्हें कहाँ नहीं रखते हैं, लेकिन व्यवहार में किसी को भी ऐसा नहीं करना चाहिए, इसलिए इस सरल चाल का उपयोग करें, सरणी के मुख्य ब्लॉक की संख्या से SHA3 हैश लें , और परिणामी संख्या को ब्लॉक की तालिका में एक कुंजी के रूप में उपयोग किया जाता है (जो, मुझे याद है, 2 ^ 256)। इस कुंजी द्वारा, सरणी डेटा का पहला ब्लॉक रखा गया है, और बाकी - इसके बाद क्रमिक रूप से, यदि आवश्यक हो। गैर-विशालकाय सरणियों के टकराने की संभावना बेहद कम है।

इस प्रकार, सिद्धांत रूप में, हमें केवल इतना करना है कि सरणी डेटा कहाँ है और बाइट बफ़र को कॉपी करके हमारे पास ब्लॉक करें। जब हम आधे से अधिक ब्लॉक आकार के छोटे प्रकारों के साथ काम करते हैं, तो हम संकलक द्वारा उत्पन्न "भोले" समाधान को कम से कम थोड़ा जीत लेंगे।

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

यहाँ वह फ़ंक्शन है जो मुझे 64-बिट हस्ताक्षरित पूर्णांक के एक सरणी में बाइट्स की एक सरणी को चालू करने के लिए मिला (हालांकि, इसे आसानी से अन्य प्रकारों के लिए अनुकूलित किया जा सकता है):

 function assign_int64_storage_from_bytes(int64[] storage to, bytes memory from) internal { //    .      int64,     8    (sizeof  Solidity  :( ) to.length = from.length / 8; //     ,  SHA3      uint256 addr; bytes32 base; assembly{ // keccak256   ,    ,          mstore(addr, to_slot) base := keccak256(addr, 32) } uint i = 0; for(uint offset = 0; offset < from.length; offset += 32) { //  32-     //     32  -  ,   ,     uint256 tmp; assembly{ tmp := mload(add(from, add(offset,32))) } //   .  ,     ,       . for(uint b = 0; b < 16; ++b) { uint shift = b*8; uint shift2 = (256 - (b+1)*8); uint low = (tmp & (0xFF << shift)) >> shift; uint high = (tmp & (0xFF << shift2)) >> shift2; tmp = tmp & ~( (0xFF << shift) | (0xFF << shift2)); tmp = tmp | (low << shift2) | (high << shift); } //      assembly{ sstore(add(base, i), tmp) } i += 1; } } 

64-बिट नंबरों के साथ, हमने कंपाइलर उत्पन्न करने वाले कोड की तुलना में 8-बिट्स के साथ उतना नहीं जीता, लेकिन फिर भी इस फ़ंक्शन में भोले के लिए 718466 गैस (7184 गैस प्रति नंबर, 898 गैस प्रति बाइट) 1003225 खपत होती है। समाधान (1003 गैस प्रति संख्या, 1254 प्रति बाइट), जो इसके उपयोग को काफी सार्थक बनाता है। और जैसा कि ऊपर बताया गया है, आप कॉल करने वाले को बाइट का पता हटाकर अधिक बचा सकते हैं।

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

आगामी परिवर्तन

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

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