 । 2019 मा मैले ईओएस नेटवर्क मेननेट DDOS'ed गरें र यसको सहमति रिसोर्सिङ मोडेलमा भएको त्रुटिको शोषण गरेर एक महिनाको लागि फ्रिज गरें। EOS त्यतिबेला शीर्ष ७ मा थियो। (   ,   ) मेरो नाम Dexaran हो। म एक ह्याकर हुँ, मैले उद्योगमा सबैभन्दा ठूलो सहमति-स्तर आक्रमणहरू मध्ये एक डिजाइन र कार्यान्वयन गरेको छु EOSGO रिपोर्ट समुदाय रिपोर्ट    । (   ) म Ethereum क्लासिक कोर विकास टोली मध्ये एक को संस्थापक हुँ Cointelegraph का लेख  मैले   डिजाइन गरेको छु,   नियमहरूको सेट जुन POW चेनहरूको लागि उद्योगको विपत्ति थियो। नाकामोटो सहमतिमा संशोधन 51% आक्रमणहरू समाधान गर्ने  सम्पादकको नोट: यो कथाले कथाको लेखकको विचारलाई प्रतिनिधित्व गर्दछ। लेखक ह्याकरनून स्टाफसँग सम्बद्ध छैन र यो कथा आफैले लेखेको छ। HackerNoon सम्पादकीय टोलीले व्याकरणीय शुद्धताको लागि मात्र कथा प्रमाणित गरेको छ र यहाँ समावेश गरिएका कुनै पनि दावीहरूलाई समर्थन/निन्दा गर्दैन। #DYOR   दुर्घटना  एक प्रयोगकर्ताले स्मार्ट-कन्ट्र्याक्टमा पठाएर $26,000,000 मूल्यको ezETH टोकन गुमाए। त्यहाँ धेरै लेखहरू र ट्वीटर थ्रेडहरू दावी छन् कि यो एक प्रयोगकर्ता गल्ती थियो, उदाहरण को लागी यो   द्वारा। CoinTelegraph    । बाह्य स्वामित्वको ठेगानाहरूमा स्थानान्तरण र स्मार्ट-अनुबंधहरूमा स्थानान्तरणहरू फरक तरिकाले काम गर्छन्। यो गलत हो। समान प्रयोगकर्ता गल्तीले Eth, NFT वा ERC-223 टोकन गुमाउने छैन  यदि प्रयोगकर्ताले गलत ठेगानामा टोकनहरू पठाउँछ (जुन स्मार्ट-कन्ट्र्याक्ट होइन) वा ठेगाना कसैको स्वामित्वमा छैन - त्यो प्रयोगकर्ताको गल्ती हुनेछ।  यद्यपि यस अवस्थामा, प्रयोगकर्ताले स्मार्ट-अनुबंधमा टोकनहरू जम्मा गरे। स्मार्ट-सम्झौताहरूले यस गल्तीहरूलाई रोक्न मानिन्छ, र तिनीहरूले पक्कै पनि त्यसो गर्न सक्छन् - उदाहरणका लागि यदि प्रयोगकर्ताले ईथर (वा कुनै अन्य नेटिभ मुद्रा), NFTs (ERC-721) वा   टोकनहरू स्मार्ट-अनुबंधमा जम्मा गर्नेछन्। तिनीहरूलाई प्राप्त गर्न डिजाइन गरिएको थिएन - त्यसपछि टोकनहरू हराउने छैन। त्यहाँ एक लेनदेन त्रुटि हुनेछ र टोकन को स्थानान्तरण मात्र हुनेछैन। ERC-223  त्रुटि ह्यान्डलिंग सफ्टवेयर सुरक्षाको सबैभन्दा आधारभूत सिद्धान्तहरू मध्ये एक हो। आह्वान त्रुटिहरू ठीकसँग ह्यान्डल गर्न सम्भव नहुने तरिकाले सफ्टवेयर डिजाइन गर्नु भनेको गभर्नेन्स प्रकार्यको लागि   परिमार्जक छुटेको जस्तै हो - त्यो सुरक्षा समस्या हुनेछ। onlyOwner  यो ERC-20 मानकको समस्या हो - यो त्रुटि ह्यान्डलिङ असम्भव बनाउने तरिकामा डिजाइन गरिएको हो। र यो एक सुरक्षा समस्या हो।   । 2023 मा,   । ERC-20 मानक असुरक्षित छ ERC-20 मानक को निर्माता आफैले पुष्टि गर्नुभयो कि यो मानक को एक सुरक्षा मुद्दा हो  मैले 2017 मा   र   रिपोर्ट गरेको छु। साथै, मैले 2017 मा यो सही समस्या समाधान गर्न ERC-223 मानक डिजाइन गरेको छु, यहाँ   थ्रेड छ जहाँ यो हाइलाइट गरिएको छ कि यो मानकले पैसाको हानि रोक्छ। यहाँ यहाँ मूल EIP-223     सुरक्षा कम्पनीहरू र विकासकर्ताहरूलाई गल्ती गरेकोमा प्रयोगकर्ताहरूलाई दोष दिन यो धेरै सजिलो छ। यद्यपि, यो विकासकर्ताको गल्ती हो कि उनीहरूले असुरक्षित मानक प्रयोग गरेर आफ्ना अनुप्रयोगहरू बनाएका थिए जसले प्रयोगकर्ताहरूको गल्तीहरूसँग व्यवहार गर्न असफल भयो जसले गर्दा यस्तो विनाशकारी क्षति भयो।   इतिहास  Ethereum Foundation लाई रिपोर्ट गर्दा यसले प्रयोगकर्ताहरूलाई आर्थिक नोक्सान पुर्‍याउन सक्छ भनेर मैले हाइलाइट गरेको छु। तिनीहरूले केही गरेनन्। 7 वर्षको लागि।  2017 मा यस मुद्दाको कारणले त्यहाँ $ 16,000 हराएको थियो।  त्यहाँ 2018 मा $ 2,000,000 हराएको थियो  2023 मा $60,000,000  नोभेम्बर 1, 2024 मा त्यहाँ $ 90,000,000 (ezETH अनुबंधमा हराएको 25M बाहेक) थिए।  अब त्यहाँ $115,000,000 छ  मेरो टोलीले हराएको टोकनको मात्रा गणना गर्ने स्क्रिप्ट विकास गर्‍यो:     https://dexaran.github.io/erc20-losses   2017 मा अर्को प्रयोगकर्ताले 130K गुमायो।   2020 मा एक प्रयोगकर्ताले आफ्नो जीवन बचत गुमाए।   2023 मा एक प्रयोगकर्ताले एक लेनदेनमा $ 240K गुमायो।   त्यसपछि Poloniex ह्याकरले $2.5M गुमाए।  मैले 2017 मा यस सुरक्षा समस्याको कारणले गर्दा ERC-20 मानक प्रवर्द्धन रोक्न अनुरोध गरेको छु, त्यहाँ कुनै प्रतिक्रिया थिएन   । https://github.com/ethereum/ethereum-org/issues/755  मैले यो मुद्दालाई EthereumCatHerders, Ethereum मा EIPs प्रबन्ध गर्ने मान्छेहरूमा बढाएको छु।  2023 मा तिनीहरूले   "हामीसँग सुरक्षा खुलासासँग कुनै सरोकार छैन, हामीसँग यसको लागि प्रक्रिया छैन"। जवाफ दिए  स्पष्टीकरण: EIPs र ERC हरू प्रस्तावहरू हुन् जुन कसैले Ethereum मा पेश गर्न सक्छ। तिनीहरू मानकहरू वा परिमार्जनहरू बन्न सक्छन् जुन devs ले Ethereum कसरी काम गर्दछ। तिनीहरू तिनीहरूको github repo मा पाठ फाइलहरू छन्।  सन्दर्भ: तिनीहरूसँग Ethereum परियोजना सुरु भएको १० वर्ष पछि EIPs मा सुरक्षा खुलासाहरूसँग सम्झौता गर्ने प्रक्रिया छैन।  म EIPs ले सुरक्षा प्रकटीकरणको लागि कसरी काम गर्छ भनेर परिमार्जन गर्ने तरिका प्रस्ताव गरिरहेको थिएँ:  https://ethereum-magicians.org/t/modification-of-eip-process-to-account-for-security-treatments/16265  मैले ERC-20 मा चेतावनी थप्न र EIPs मा मुद्दा कागजात गर्न प्रस्ताव गरें। यहाँ तिनीहरूको कल छ, जहाँ उनीहरूले निर्णय गरे कि म गएर अर्को सूचनात्मक EIP सिर्जना गर्न आवश्यक छ जसले EIP-20 मा एक जोखिम प्रकट गर्दछ:  https://github.com/ethcatherders/EIPIP/issues/257#issuecomment-1693372317  मैले त्यो गरें। तिनीहरूले त्यस पछि मेरो खुलासा EIP   । अस्वीकार गरे  मैले EthereumMagicians फोरममा वर्णन गरेको मेरो प्रारम्भिक विचारलाई पुनर्जीवित गर्ने प्रस्ताव लिएको छु जसले 2024 मा EIPs को "सुरक्षा विचारहरू" खण्डमा सुरक्षा खुलासा गर्न अनुमति दिनेछ।  यहाँ EIP सम्पादकहरूसँग मेरो छलफल छ:  https://www.youtube.com/watch?v=PKkJNqcozhw&t=744s  नतिजाको रूपमा EIP सम्पादकहरूले मलाई भने कि तिनीहरू त्यसमा मतदान गर्न जाँदैछन्:  https://github.com/ethcatherders/EIPIP/issues/349  मेरो प्रस्ताव अस्वीकृत भयो। EIPs मा सुरक्षा खुलासाहरु संग सम्झौता गर्न को लागी अझै कुनै प्रक्रिया छैन। ERC-20 को समस्या तय भएको छैन। यो समस्याको रूपमा रिपोर्ट वा दस्तावेजीकरण गरिएको छैन त्यसैले कार्यान्वयनकर्ताहरूले यसलाई बारम्बार पुन: उत्पादन गरिरहन्छन्।   अनुचित लेखा परीक्षकहरू  मैले व्यक्तिगत रूपमा यो मुद्दा OpenZeppelin लाई रिपोर्ट गरेको छु, 3 पटक समाधान गर्न अनुरोध गर्दै।  2018 मा  https://github.com/OpenZeppelin/openzeppelin-contracts/issues/729  २०२३ मा  https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4451  तिनीहरूले अघिल्लो दुई अस्वीकार गरेपछि, मैले यो मुद्दाको गम्भीरता प्रदर्शन गर्ने तरिकामा रिपोर्ट गर्ने निर्णय गरें, त्यसैले मैले यसलाई तिनीहरूको बग बाउन्टीमा पेश गरें किनभने यो तिनीहरूको आफ्नै नियमहरू अनुसार "महत्वपूर्ण सुरक्षा जोखिम" मापदण्डमा फिट हुन्छ    https:// /github.com/OpenZeppelin/openzeppelin-contracts/issues/4474#issuecomment-1646901022  OpenZeppelin ले यसलाई "अनप्याच गरिएको जोखिमको सार्वजनिक खुलासा" को साथ अस्वीकार गर्‍यो (जसले यो कम्तिमा सुरक्षा समस्या हो भनेर पुष्टि गर्दछ)।  केही दिन पहिले Devcon7 मा, OpenZeppelin को उही केटालाई एउटा प्रश्न सोधिएको थियो जसले आफ्नो github मा त्यो समस्याको बारेमा एउटा मुद्दा बन्द गर्यो:  https://www.youtube.com/watch?app=desktop&v=DKJYpdXsOwQ&start=406  यो रिपोर्ट गरिएको 6 वर्ष पछि र यसले तिनीहरूका प्रयोगकर्ताहरूलाई $ 115,000,000 नोक्सान गर्यो।  उनीहरुको प्रतिक्रिया पनि सत्य होइन । खुला मुद्दा हुनुको सट्टा, तिनीहरूले मैले खोलेका 3 मुद्दाहरू बन्द गरे र मैले गरेको सिफारिसहरू अस्वीकार गरे।   निष्कर्ष  Ethereum Foundation ले समस्या हाइलाइट गर्ने कुनै पनि प्रयासलाई सेन्सर गर्दैछ, जसले पारिस्थितिक प्रणालीका प्रयोगकर्ताहरूलाई $115,000,000 गुमाएको छ। समस्या घोषणा गरिएको छैन, खुलासा राम्रोसँग ह्यान्डल गरिएको छैन, कार्यान्वयनकर्ताहरूले यसलाई नयाँ अनुबंधहरूमा पुन: उत्पादन गरिरहन्छन्।  मलाई लाग्छ कि तिनीहरूले यो खुलासा गर्न उनीहरूको प्रतिष्ठाको लागि धेरै हानिकारक हुनेछ भनेर विचार गर्छन्।  OpenZeppelin जस्ता लेखा परीक्षकहरूले पनि यस मुद्दालाई खुलासा गर्दैनन्, सम्भवतः तिनीहरूसँग चासोको द्वन्द्व भएको कारणले गर्दा तिनीहरूले पहिले नै सयौं ERC-20 अनुबंधहरूमा "सुरक्षित" लेबल राखेका छन् जुन तिनीहरूले लेखा परीक्षण गरेका छन्।  Devs भनिरहेका छन् "हामी भर्खरै मानक लागू गर्दैछौं जसरी यो छ।"  मानक EIP प्रक्रिया द्वारा शासित छ, EIP प्रक्रिया सुरक्षा खुलासा संग व्यवहार को लागी बनाइएको छैन।  EIP प्रक्रिया परिवर्तन गर्नुपर्छ। ERC-20 मुद्दा खुलासा र राम्रोसँग दस्तावेज हुनुपर्छ। आदर्श रूपमा, नयाँ मापदण्ड लागू गर्नुपर्छ। क्षति कम गर्नको लागि ERC-20 मा "ब्यान्डेड" को सेट लागू गर्नु केहि नगर्नु भन्दा राम्रो हो, तर यसले समस्याको समाधान गर्दैन।  "समस्या वालेट स्तरमा हल गर्न सकिन्छ" भन्ने सबैजना सुरक्षा विशेषज्ञताको अभाव छ। सफ्टवेयर सुरक्षा मा   को एक सिद्धान्त छ जसको मतलब यो हो कि तपाईं असुरक्षित सफ्टवेयर को एक टुक्रा बनाउन सक्नुहुन्न, सबैलाई यसलाई कसरी प्रयोग गर्ने भनेर बताउनुहोस् ताकि यसले तपाइँका प्रयोगकर्ताहरूलाई असर गर्दैन र यसले क्षति नपुग्ने बहाना गर्दछ। वित्तीय क्षेत्रमा छैन। त्यो दृष्टिकोणले वेब डिजाइनमा काम गर्न सक्छ, उदाहरणका लागि, जहाँ गल्तीको लागत कसैले आफ्नो वेब पृष्ठको लागि उचित फन्ट लोड गर्न सक्षम नभएको हो। वित्तीय उद्योगमा यसले लाखौं डलर गुमाउने परिणाम हो। डिजाइन द्वारा सुरक्षित  यो ग्यारेन्टी गर्न बिल्कुल असम्भव छ कि मानव सभ्यताको सम्पूर्ण भविष्यमा सबै वालेट विकासकर्ताहरूले सधैं सबै आवश्यक फिक्सहरू सही रूपमा लागू गर्नेछन्।

Read My Stories

यो अडियो कथाको मौलिक भाषामा निर्माण गरिएको हो!

धेरै लामो; पढ्नकाे लागि

Download free Tech Leaders Productivity Report!

व्यापारीले ezETH टोकनहरूमा $ 26M गुमायो: मिडियाले प्रयोगकर्तालाई दोष दिन्छ, ह्याकरले ERC-20 त्रुटिहरू बोलाउँछ

About Author

टिप्पणीहरू

ह्याङ्ग ट्यागहरू

यो लेख मा प्रस्तुत गरिएको थियो

Related Stories

Transcripts Don't Lie: HackerNoon's New YouTube Feature Keeps Readers on the Same Page

Uber Still Can't Turn a Profit

The HackerNoon Newsletter: No Startup Has Ever Failed Because it Didn’t Have a Blog (2/15/2025)

The HackerNoon Newsletter: Vibe Coding - A New System of the World (3/9/2025)

Transcripts Don't Lie: HackerNoon's New YouTube Feature Keeps Readers on the Same Page

Uber Still Can't Turn a Profit

The HackerNoon Newsletter: No Startup Has Ever Failed Because it Didn’t Have a Blog (2/15/2025)

The HackerNoon Newsletter: Vibe Coding - A New System of the World (3/9/2025)

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps