क्रिप्टो इस तरह से जारी नहीं रह सकता: एक ब्लॉकचेन प्रैक्टिशनर की ओर से एक उद्योग आत्म-बचाव पहल

एक घटना केवल संपत्ति ही नहीं, बल्कि भरोसा भी छीन लेती है। क्रिप्टो इस तरह नहीं चल सकता; हमें खुद को बचाना होगा।

लेखक: रॉबर्ट माओ, ArcBlock के संस्थापक और CEO

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

क्रिप्टो इस तरह जारी नहीं रह सकता। बार-बार, बड़े पैमाने की चोरियाँ न केवल संपत्ति ले जाती हैं, बल्कि प्रतिभागियों का पूरे उद्योग पर से विश्वास भी छीन लेती हैं। हमें स्वयं को बचाना होगा।

29 अक्टूबर, 2026 को Binance में एक बड़ी सुरक्षा घटना हुई। इसकी प्रारंभिक घोषणा में अनुमान लगाया गया कि लगभग $6.3 बिलियन की संपत्ति प्रभावित हुई, और प्रभावित संपत्ति में से लगभग $3 बिलियन फ्रीज़ कर दी गई थी; जाँच शुरू में एक DevOps इंजीनियर के लैपटॉप की ओर इंगित करती थी, और बाद में अन्य संभावित घुसपैठ बिंदु भी खोजे गए। Binance ने यह भी कहा कि वॉलेट निजी कुंजी लीक होने का कोई सबूत नहीं मिला है। प्रभावित राशि अंतिम शुद्ध हानि नहीं है, और पूरी हमला श्रृंखला अभी भी जाँच के अधीन है। [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)

यह पहल Ethereum और Solana जैसे ब्लॉकचेन परियोजनाओं के निर्माताओं को संबोधित है, और Binance, Coinbase, Kraken, तथा सभी एक्सचेंजों, वॉलेट्स, प्रोटोकॉल्स और सुरक्षा निर्माताओं को भी जो भाग लेने को इच्छुक हैं: आइए हम मिलकर संपत्ति की सुरक्षा के लिए आधार का पुनर्निर्माण करें। मैं भाग लेने को तैयार हूँ, और मुझे आशा है कि अधिक लोग मिलकर कार्य करेंगे।

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

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

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

ArcBlock के संस्थापक और क्रिप्टो तथा ब्लॉकचेन के एक व्यवसायी के रूप में, मैं ऐसे परिणाम को स्वीकार करने को तैयार नहीं हूँ। मेरा मानना है कि इस उद्योग में ऐसा मूल्य है जो संरक्षित करने योग्य है, और मेरा यह भी मानना है कि हमें अपनी सुरक्षा नींव की जिम्मेदारी लेनी होगी। यदि हम अगली घटना की निष्क्रिय प्रतीक्षा करते रहेंगे, तो बार-बार होने वाला रक्तस्राव अंततः वह सब कुछ नष्ट कर सकता है जो हमने मिलकर बनाया है।तो, मैं यह पहल शुरू करना चाहता हूँ: एक्सचेंज, वॉलेट और ब्लॉकचेन के निर्माताओं को संयुक्त रूप से परिसंपत्ति नियंत्रण और सुरक्षा सत्यापन की नींव का पुनर्निर्माण करना चाहिए, ताकि किसी एक घुसपैठ से होने वाले नुकसान का दायरा सीमित हो। नीचे दी गई समयरेखा बताती है कि बदलाव क्यों आवश्यक है; इसके बाद दिया गया तकनीकी प्रस्ताव वह कार्य है जिसे मेरा मानना है कि हम शुरू कर सकते हैं।

2008 में, सातोशी नाकामोतो ने एक पीयर-टू-पीयर इलेक्ट्रॉनिक नकद प्रणाली प्रस्तावित की, जिसका प्रयास भुगतान को विश्वसनीय मध्यस्थों पर कम निर्भर बनाना था। [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) फिर भी तब से हुई प्रमुख घटनाओं ने बार-बार इस समस्या को उजागर किया है कि धन, प्राधिकरण और सॉफ़्टवेयर निर्भरताएँ फिर से केंद्रित हो रही हैं।

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

2008 · बिटकॉइन व्हाइटपेपर

प्रारंभिक बिंदु

बिटकॉइन व्हाइटपेपर ने वित्तीय संस्थानों को मध्यस्थ के रूप में शामिल किए बिना पीयर-टू-पीयर भुगतान प्रस्तावित किया।

स्रोत

2011–2014 · Mt. Gox दीर्घकालिक चोरी

CEX

Mt. Gox ने दीर्घकालिक चोरी का सामना किया और अंततः परिचालन बंद कर दिया। बाद में अमेरिकी न्याय विभाग के अभियोग में आरोप लगाया गया कि 2011 और 2014 के बीच लगभग 647,000 BTC चोरी हुए। यह 2014 में एक ही दिन का हमला नहीं था।

स्रोत

2012 · Bitcoinica और Bitfloor

CEX / कस्टोडियल अवसंरचना

Bitcoinica का Linode होस्टिंग वातावरण भंग हुआ; उसी वर्ष, Bitfloor का अनएन्क्रिप्टेड वॉलेट बैकअप हमले का प्रवेश बिंदु बन गया। प्लेटफ़ॉर्म के पीछे के सर्वर और बैकअप भी परिसंपत्ति सुरक्षा सीमा का हिस्सा हैं।

स्रोत

2015 · Bitstamp हॉट वॉलेट

CEX

Bitstamp का हॉट वॉलेट भंग हुआ, और परिचालन वातावरण का बाद में पुनर्निर्माण किया गया। घटना के दायरे और ऑफ़लाइन भंडार के बीच आधिकारिक भेद ने दिखाया कि अलगाव जोखिम के दायरे को सीमित कर सकता है।

स्रोत

2016 · Bitfinex

CEX

Bitfinex से लगभग 120,000 BTC चोरी हुए। मल्टीसिग्नेचर व्यवस्थाओं के लिए अभी भी एंड-टू-एंड स्वतंत्र प्राधिकरण और सत्यापन आवश्यक है।

स्रोत 1 · स्रोत 2

2016 · The DAO

ऑन-चेन प्रोटोकॉल

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

स्रोत 1 · स्रोत 2

2017 · Parity साझा वॉलेट लाइब्रेरी

अनुबंध वॉलेट

Parity साझा वॉलेट लाइब्रेरी नष्ट हो गई, और लगभग 513,000 ETH फ्रीज़ हो गए। भले ही स्थानांतरित न हों, साझा कोड निर्भरताओं के कारण धन अप्रयोगযোগ্য हो सकता है।

स्रोत

2018 · Coincheck

CEXCoincheck का NEM हॉट वॉलेट चोरी हो गया। ऑफ़लाइन रिज़र्व, हॉट वॉलेट अनुमतियों और व्यावसायिक आवश्यकताओं के बीच की सीमा एक बार फिर समस्या बन गई।

स्रोत

2019 · Binance

CEX

Binance ने घोषणा की कि एक ही लेन-देन में 7,000 BTC निकाले गए। हस्ताक्षर से पहले बड़े पैमाने पर परिसंपत्ति बहिर्वाह को सीमित करने की आवश्यकता है।

स्रोत

2020 · KuCoin

CEX

KuCoin हॉट वॉलेट घटना, जिसमें बाद में बहुपक्षीय सहयोग के माध्यम से बड़ी मात्रा में परिसंपत्तियाँ वसूल की गईं। सकल चोरी की गई राशि और अंतिम हानि एक ही संख्या नहीं है।

स्रोत

2021 · Poly Network

क्रॉस-चेन प्रोटोकॉल

Poly Network से लगभग $612 मिलियन की परिसंपत्तियाँ स्थानांतरित की गईं और बाद में चरणों में वापस की गईं। क्रॉस-चेन प्राधिकरण और परिसंपत्ति नियंत्रण केवल सामान्य व्यावसायिक मार्गों से नहीं टिक सकते।

स्रोत

2022 · Ronin bridge

ब्रिज

Ronin वैलिडेटर अनुमतियाँ compromised हुईं, और 173,600 ETH तथा 25.5 मिलियन USDC स्थानांतरित किए गए। कई वैलिडेटरों की कुंजियाँ भी एक ही हमला श्रृंखला में फँस सकती हैं।

स्रोत

2022 · Slope wallet

वॉलेट

Solana इकोसिस्टम में Slope wallet घटना। Solana ने आधिकारिक रूप से कहा कि निजी कुंजी जानकारी गलती से एक एप्लिकेशन मॉनिटरिंग सेवा को प्रेषित हुई; यह Solana सहमति का उल्लंघन नहीं था।

स्रोत

2023 · Euler

लेंडिंग प्रोटोकॉल

प्रोटोकॉल भेद्यता के कारण Euler से लगभग $197 मिलियन की परिसंपत्तियाँ स्थानांतरित की गईं और बाद में वसूल की गईं। एक ही लेन-देन में जटिल संयोजन व्यावसायिक तर्क दोषों को बढ़ा सकते हैं।

स्रोत

2023 · Ledger Connect Kit

वॉलेट कनेक्शन टूल

Ledger Connect Kit पर आपूर्ति श्रृंखला हमला हुआ, और दुर्भावनापूर्ण कोड एप्लिकेशन फ्रंटएंड में प्रवेश कर गया। हार्डवेयर डिवाइस सुरक्षा लेन-देन सामग्री सत्यापन का स्थान नहीं ले सकती।

स्रोत

2024 · DMM Bitcoin

CEX

DMM Bitcoin से लगभग $308 मिलियन चोरी हुए। FBI और अन्य एजेंसियों ने बाद में संबंधित कर्मियों और हस्ताक्षर श्रृंखला को लक्षित सोशल इंजीनियरिंग हमलों का खुलासा किया।

स्रोत

2024 · Radiant Capital

लेंडिंग प्रोटोकॉल / हस्ताक्षर

Radiant Capital से लगभग $50 मिलियन चोरी हुए, और कई डेवलपर डिवाइस compromised हुए। बहुपक्षीय हस्ताक्षर अभी भी सामूहिक रूप से दूषित लेन-देन जानकारी पर निर्भर हो सकते हैं।

स्रोत

2025 · Bybit / Safe

CEX / वॉलेट फ्रंटएंड

लगभग $1.5 बिलियन की Bybit घटना में Safe डेवलपर वातावरण और फ्रंटएंड शामिल थे, और हस्ताक्षरकर्ताओं ने एक ऐसे लेन-देन को मंजूरी दी जिसने वॉलेट नियंत्रण तर्क बदल दिया।

स्रोत 1 · स्रोत 2

2025 · Cetus DEX

DEX

Sui पर Cetus की लगभग $223 मिलियन की घटना, जिसमें शोधकर्ताओं ने एक गणित लाइब्रेरी में दोष की ओर इशारा किया। गैर-EVM वातावरणों को भी इसी तरह अपने कोड और परिसंपत्ति जोखिम के दायरे की जाँच करनी चाहिए।

स्रोत

2026-07 · COLDCARD यादृच्छिक संख्या दोष

हार्डवेयर वॉलेट / सीड जनरेशनएक फर्मवेयर दोष ने सीड जनरेशन को कमज़ोर कर दिया, जिससे हमलावरों को डिवाइस के ऑफ़लाइन रहने के दौरान संबंधित निजी कुंजियों (private keys) का पुनर्निर्माण करने की अनुमति मिली। अपग्रेड करके उन कमज़ोर सीड्स को ठीक नहीं किया जा सकता जो पहले ही जनरेट हो चुके हैं; सलाह के अनुसार माइग्रेशन अभी भी आवश्यक है।

स्रोत

2026-10 · Ledger हार्डवेयर इम्प्लांट

हार्डवेयर वॉलेट / वितरण हमला

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

स्रोत

2026 · Binance मल्टी-चेन घटना

CEX / मल्टी-चेन

Binance ने शुरू में अनुमान लगाया कि लगभग $6.3 बिलियन की संपत्तियाँ प्रभावित हुईं, और अन्य संभावित घुसपैठ बिंदुओं की जाँच अभी भी जारी है। एक ही ऑपरेटिंग सिस्टम एक साथ कई नेटवर्कों में संपत्तियों को उजागर कर सकता है।

स्रोत 1 · स्रोत 2 · स्रोत 3

यहाँ CEXs भी हैं, लेकिन विकेंद्रीकृत एक्सचेंज, लेंडिंग प्रोटोकॉल और ब्रिज भी हैं; संपत्तियाँ चोरी हुई हैं, और संपत्तियाँ फ़्रीज़ की गई हैं। हमले अलग-अलग परतों पर होते हैं, और उपचार के तरीके अलग-अलग होते हैं। मैं इस सब को एक ही वाक्य "उपयोगकर्ता अपनी निजी कुंजियों की सुरक्षा करने में विफल रहे" तक सीमित करने का विरोध करता हूँ। उपयोगकर्ता कैसे जान सकते हैं कि किसी उपकरण का विकास वातावरण, कोई साझा लाइब्रेरी, या कोई अगम्य प्राधिकरण उनकी सभी संपत्तियों का प्रवेश बिंदु बन जाएगा?

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

Ethereum का योगदान महत्वपूर्ण है। इसने अधिक लोगों को ऑन-चेन एप्लिकेशन लिखने में सक्षम बनाया और उपकरणों तथा विकास अनुभव का एक समृद्ध समूह विकसित किया। लेकिन आज, कई नए चेन और L2s (लेयर-2 स्केलिंग नेटवर्क) EVM संगतता को अपना प्राथमिक लक्ष्य मानते हैं। EVM, वह वर्चुअल मशीन जो Ethereum स्मार्ट कॉन्ट्रैक्ट्स को निष्पादित करती है, एक व्यापक रूप से प्रतिलिपित तकनीकी पूर्वधारणा बनती जा रही है। संगतता एप्लिकेशन माइग्रेशन को सुविधाजनक बनाती है; Unichain जैसी परियोजनाओं का दस्तावेज़ीकरण स्पष्ट रूप से समतुल्य निष्पादन वातावरण के मूल्य के रूप में Ethereum टूलींग के पुनः उपयोग का हवाला देता है। [[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)

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

EIP-7702 इस समस्या को बहुत स्पष्ट करता है। एक सामान्य हस्तांतरण है "इस बार कितना, किसे"; एक प्रत्यायोजन प्राधिकरण हो सकता है "अब से, इस कोड खंड को मेरे खाते की ओर से संचालन निष्पादित करने दें।" इसके लक्ष्य उपयोगकर्ता अनुभव को बेहतर बनाना और अनुमतियों को सूक्ष्म बनाना हैं, लेकिन प्रत्यायोजन स्थापित करना स्वयं व्यापक निष्पादन क्षमता प्रदान करता है, और सूक्ष्म-कणीय अनुमतियाँ अभी भी प्रत्यायोजित कोड द्वारा सही ढंग से कार्यान्वित की जानी चाहिए। [[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) मिनफेंग क्यू एट अल. का प्रीप्रिंट "EIP-7702 फिशिंग अटैक" ऐसे प्राधिकरणों पर हस्ताक्षर करने के लिए प्रेरित करने के बाद किसी खाते को लगातार नियंत्रित करने के पथ का अध्ययन करता है। [[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) जैसे-जैसे सुविधा बढ़ती है, सुरक्षा जिम्मेदारी भी बढ़ती है; पूर्व को सरलता से उपयोगकर्ताओं को नहीं सौंपा जा सकता।

यह बिनेंस घटना कई चेनों में फैली है, और जांच अभी पूरी नहीं हुई है, इसलिए संपूर्ण प्रभाव को सीधे EIP-7702 या EVM को नहीं attributed किया जा सकता। रीएंट्रेंसी, हस्ताक्षर सेवाओं का समझौता, और फ्रंट-एंड छेड़छाड़ भी एक ही भेद्यता नहीं हैं। लेकिन ऐसे भेदों को वास्तुकला पर सवाल उठाना बंद करने का बहाना नहीं बनना चाहिए: आधार परत ऊपरी परतों की त्रुटियों के लिए अधिक ऐसे प्रतिबंध क्यों नहीं रखती जिन्हें आसानी से बायपास न किया जा सके?

MEV भी मुझे असंतुष्ट करता है। यह उस स्थान को संदर्भित करता है जहाँ प्रतिभागी लेनदेन के समावेश, बहिष्करण और क्रमबद्धता के माध्यम से अतिरिक्त मूल्य प्राप्त करते हैं। मेरे लिए, क्रमबद्धता शक्ति का उपयोग करके उपयोगकर्ता लेनदेन को सैंडविच करना और उनके निष्पादन परिणामों को बिगाड़ना एक बग के रूप में माना जाना चाहिए जिसे ठीक करने की आवश्यकता है, न कि एक विशेषता के रूप में पैकेज किया जाना चाहिए जिसे संरक्षित करने योग्य माना जाए क्योंकि कोई इससे लाभ कमा सकता है। एथेरियम का अपना दस्तावेज़ भी स्पष्ट रूप से उपयोगकर्ताओं के लिए लेनदेन सैंडविचिंग के नुकसान और नेटवर्क स्थिरता के लिए MEV के जोखिम को स्वीकार करता है। [[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEV एथेरियम के लिए अद्वितीय नहीं है और इसमें आर्बिट्राज और लिक्विडेशन जैसी विभिन्न गतिविधियाँ भी शामिल हैं; उद्योग में पहले से ही शमन अनुसंधान मौजूद है। मेरी आलोचना यह है कि नेटवर्क को बनाए रखने का प्रोत्साहन उपयोगकर्ताओं की लेनदेन शर्तों को बलिदान करने का कारण नहीं बन सकता। एक बेहतर लेनदेन प्रणाली को न्यूनतम डिलीवरी परिणाम और अनुमत शुल्क को प्राधिकरण में लिखना चाहिए, और ऑर्डरर के लिए अधूरी जानकारी का उपयोग करके उपयोगकर्ताओं को नुकसान पहुँचाने की गुंजाइश को सीमित करना चाहिए।मैंने हमेशा महसूस किया है कि एथेरियम का क्रिप्टो पर प्रभाव कुछ हद तक PHP के इंटरनेट पर प्रभाव जैसा है: इसने कई लोगों को चीज़ें बनाने में सक्षम बनाया, और इसने इंजीनियरिंग ऋण भी छोड़ा जिसे चुकाने में लंबा समय लगेगा। PHP को अक्टूबर 2026 में एक गंभीर रिमोट कोड एक्ज़ीक्यूशन भेद्यता को अभी भी ठीक करना पड़ा। परिपक्वता और लोकप्रियता निरंतर सुदृढ़ीकरण का स्थान नहीं ले सकतीं। [[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) इंटरनेट में जो मूल्यवान है वह यह है कि भाषाएँ, फ्रेमवर्क और क्लाउड सेवाएँ अलग-अलग विकसित हो सकती हैं। हमें विभिन्न परिसंपत्ति मॉडलों और निष्पादन विधियों को भी विकसित होते रहने देना चाहिए, न कि "एक ही वर्चुअल मशीन के साथ संगतता" को पारिस्थितिकी तंत्र में भाग लेने का टिकट मानना चाहिए।

इसलिए, मैं बिटकॉइन, सोलाना और रिपल/XRP लेजर पारिस्थितिकी तंत्रों, साथ ही ArcBlock सहित बिल्डरों से एक साझा सुरक्षा नींव के निर्माण में गंभीरता से भाग लेने का आह्वान करता हूँ। मानकों और अंतर-संचालनीयता में भाग लेने के लिए पहले स्वयं को एथेरियम में बदलने की आवश्यकता नहीं है। विविधता को परिसंपत्ति नियंत्रण और सत्यापन विधियों में लागू किया जाना चाहिए और सार्वजनिक जाँच के लिए खुला होना चाहिए। Slope और Cetus की घटनाओं ने पहले ही हमें याद दिला दिया है कि गैर-EVM के पास भी सुरक्षा छूट नहीं है।

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

1. अंतर्निहित जोखिम नियंत्रणों को परिसंपत्तियों के निपटान की शक्ति को सीमित करने दें

बड़े वॉलेट को प्राप्तकर्ता श्वेतसूची, संचयी व्यय सीमाएँ और नए प्राप्तकर्ताओं के लिए प्रतीक्षा अवधि निर्धारित करने में सक्षम होना चाहिए। मुख्य बात यह है कि इन नियमों को उसी दैनिक लेनदेन कुंजी द्वारा तुरंत रद्द नहीं किया जा सकता। नियमों को संशोधित करने के लिए स्वतंत्र प्राधिकरण आवश्यक है और निगरानी और निरसन के लिए समय छोड़ना चाहिए।मौजूदा स्मार्ट अकाउंट्स के पास पहले से ही एक कार्यान्वयन आधार है, उदाहरण के लिए Safe Guards मल्टीसिग के अतिरिक्त लेनदेन प्रतिबंध जोड़ सकता है। [[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) हमें इसे एक ऐसी बुनियादी क्षमता बनाना है जिसे अपनाना आसान हो और जो सभी परिसंपत्ति नियंत्रण मार्गों को कवर करे। यदि केवल सीधे ट्रांसफर प्रतिबंधित हों जबकि असीमित अनुमोदनों, मॉड्यूलों या अपग्रेडों के माध्यम से बायपास की अनुमति हो, तो सुरक्षा विफल हो जाएगी। व्हाइटलिस्ट अनुबंध अपग्रेड किया जा सकता है या नहीं और प्राप्तकर्ता की अनुमतियाँ बदली हैं या नहीं, यह भी सत्यापन के दायरे में आना चाहिए। Apple का Activation Lock रोज़मर्रा के जीवन से एक प्रेरणा देता है: यह चोरी हुए उपकरणों के पुनः सक्रियण को प्रतिबंधित करता है और कुछ चोरी हुए पुर्जों के कैलिब्रेशन को सीमित करता है, जिसका उद्देश्य चोरी के बाद शोषण की जा सकने वाली कीमत को कम करना है। [[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) वॉलेट्स को भी इसी दिशा में डिज़ाइन करना उचित है। यदि हमलावर को कोई कुंजी मिल जाए, तो नकदीकरण की जा सकने वाली परिसंपत्तियों की सीमा सीमित रहती है, और हमले से अपेक्षित प्रतिफल घट सकता है; सेवाओं को बाधित करने जैसे जोखिमों को अलग से संभालना अभी भी आवश्यक है।

इसे मैं परिसंपत्ति सुरक्षा का "संविधान" कहता हूँ: परिचालन प्राधिकार से समझौता हो सकता है, लेकिन सीमाओं को संशोधित करने का प्राधिकार स्वतंत्र रहना चाहिए। पुनर्प्राप्ति प्रक्रियाओं को भी सीमित किया जाना चाहिए, ताकि एक भी गलत कॉन्फ़िगरेशन परिसंपत्तियों को स्थायी रूप से लॉक न कर दे।

II. वॉलेट्स को सुरक्षा की ज़िम्मेदारी उठानी चाहिए, न कि केवल म्नेमोनिक शब्द सौंप देना चाहिए

आज की वॉलेट प्रणालियों के प्रति मेरी गहरी असंतोष है: यदि कोई उत्पाद किसी आम व्यक्ति से शब्दों का एक सेट कॉपी करने को कहता है, उनसे अपेक्षा करता है कि वे उन्हें कभी लीक न करें, खोएँ नहीं, या धोखे से न दें, और फिर बाद की सभी विफलताओं का श्रेय उपयोगकर्ता की ज़िम्मेदारी को देता है, तो मैं इसे एक गैर-ज़िम्मेदाराना डिज़ाइन मानता हूँ। स्व-अभिरक्षा लोगों को नियंत्रण देनी चाहिए, और उन्हें उपयोगी सुरक्षा और पुनर्प्राप्ति क्षमताएँ भी देनी चाहिए। इससे हर उपयोगकर्ता को पहले सुरक्षा विशेषज्ञ बनने की आवश्यकता नहीं होनी चाहिए। यह भी एक सीमा है जिसे Crypto को अधिक आम उपयोगकर्ताओं तक पहुँचने के लिए पार करना होगा।हाल की घटनाओं ने इस समस्या को सीधे मेज़ पर रख दिया है। अक्टूबर 2026 में, Ledger ने पुष्टि की कि हमलावरों ने असली उपकरणों को संशोधित किया और फिर उन्हें दक्षिण-पूर्व एशिया में वितरण चैनलों के माध्यम से बाज़ार में वापस भेज दिया, जिसमें प्रत्यारोपित घटक इनिशियलाइज़ेशन के दौरान रिकवरी शब्द चुरा रहे थे। Ledger ने इसे फ़ैक्टरी छोड़ने के बाद उपकरण पर एक स्थानीयकृत वितरण हमला बताया, न कि इसकी चिप, ऑपरेटिंग सिस्टम या सर्वर से समझौता। [[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) COLDCARD की जुलाई की घटना में फ़र्मवेयर ने सीड जनरेशन को कमज़ोर किया: हमलावर को संबंधित निजी कुंजियों का पुनर्निर्माण करने के लिए उपकरण को दूर से नियंत्रित करने की आवश्यकता नहीं थी। फ़र्मवेयर अपडेट करने से जनरेशन प्रक्रिया आगे के लिए ठीक हो जाती है, लेकिन पहले से उत्पन्न कमज़ोर सीड्स को अभी भी माइग्रेट करने की आवश्यकता है। [[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)

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

सुधार का लक्ष्य पूर्ण वॉलेट जीवनचक्र होना चाहिए: कुंजियाँ कैसे उत्पन्न होती हैं, लेन-देन कैसे समझाए जाते हैं, अनुमतियाँ कैसे अलग की जाती हैं, और उपकरण खो जाने के बाद रिकवरी कैसे काम करती है। अकाउंट एब्स्ट्रैक्शन, अर्थात् खातों को प्रोग्रामेबल नियमों के माध्यम से प्राधिकरण सत्यापित करने की अनुमति देना, और SLIP-39 जैसे थ्रेशोल्ड बैकअप, दोनों के पास पहले से मानक और कार्यान्वयन आधार हैं, इसलिए यह नहीं कहा जा सकता कि उद्योग में कोई इन पर काम नहीं कर रहा। [[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) लेकिन हमें इन क्षमताओं को परीक्षित, उपयोग में आसान सुरक्षा उपाय बनाना होगा, न कि उपयोगकर्ताओं को स्वयं जटिल योजनाएँ जोड़ने देना।

मनेमोनिक शब्दों का साधारण अस्पष्टीकरण पर्याप्त नहीं है। अधिक विश्वसनीय दिशाओं में समीक्षित एन्क्रिप्टेड बैकअप, थ्रेशोल्ड रिकवरी, और स्वतंत्र उपकरण प्राधिकरण शामिल हैं, और उपयोगकर्ताओं द्वारा बड़ी मात्रा में संपत्ति जमा करने से पहले रिकवरी अभ्यास पूरा करना। बैकअप शार्ड और मल्टीसिग अलग-अलग परतें हैं: पूर्व रिकवरी के दौरान एक ही रहस्य में पुनः संयोजित हो सकते हैं, जबकि बाद में लेन-देन को स्वीकृत करने के लिए कई स्वतंत्र हस्ताक्षरकर्ताओं की आवश्यकता होती है। रिकवरी सेवाएँ चुपचाप एक नई मास्टर कुंजी नहीं बननी चाहिए, और न ही एक अतिरिक्त पासवर्ड एक और जाल बनना चाहिए जहाँ इसे खोने का अर्थ अपूरणीय हानि हो।व्यक्तिगत वॉलेट और एक्सचेंज वॉलेट सिस्टम लेन-देन विवरण, हस्ताक्षर अनुरोध, परिसंपत्ति प्रतिबंध और पुनर्प्राप्ति प्रक्रियाओं के लिए सुरक्षा विनिर्देश साझा कर सकते हैं, जबकि भिन्न सीमाएँ और अनुमोदन नीतियाँ अपना सकते हैं। बिटकॉइन का PSBT पहले से ही टूल्स के बीच अहस्ताक्षरित लेन-देन पारित करने के लिए एक प्रारूप प्रदान करता है, और यह सामान्य इंटरफ़ेस आगे विकसित करने योग्य है। [[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) जो सामान्य है वह है जाँच योग्य सुरक्षा आवश्यकताएँ; प्रत्येक चेन को अभी भी अपने स्वयं के अनुकूलन नियम स्पष्ट करने की आवश्यकता है। वॉलेट को स्पष्ट रूप से प्रस्तुत करना चाहिए कि यह हस्ताक्षर क्या स्थानांतरित करेगा और इसके बाद किसे कितना अधिकार देगा, और स्वतंत्र नीतियों को सीमा-उल्लंघन संचालनों को अस्वीकार करना चाहिए; एक सुंदर पुष्टिकरण पृष्ठ पर्याप्त नहीं है।

III. न्यूनतम आवश्यक प्रकटीकरण के साथ सत्यापनीयता प्राप्त करें

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

W3C की सत्यापनीय क्रेडेंशियल प्रणाली में चयनात्मक प्रकटीकरण के लिए पहले से ही एक तकनीकी मार्ग है; हालाँकि, यह सिद्ध करना कि इनपुट प्रामाणिक हैं, क्रेडेंशियल वैध बने हुए हैं, और स्थिति को कैसे रद्द किया जाता है, अभी भी स्पष्ट करने की आवश्यकता है। [[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) शून्य-ज्ञान प्रमाण (ZK) अपनाने से लेन-देन राशियाँ और संबंध स्वतः नहीं छिपते; स्केलिंग प्रमाण और गोपनीयता संरक्षण भिन्न लक्ष्य हैं।

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

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

IV. लेन-देन सेवाओं को यथासंभव केंद्रीकृत अभिरक्षा से मुक्त बनाएंट्रेड मिलान, पथ खोज और परिसंपत्ति निपटान को अलग-अलग डिज़ाइन किया जाना चाहिए। ट्रेडिंग एंट्री पॉइंट प्रदान करने वाली सेवा को केवल वर्तमान निपटान को यथासंभव पूरा करने के लिए आवश्यक अनुमतियाँ ही प्राप्त करनी चाहिए, ताकि शेष समय में उपयोगकर्ता की परिसंपत्तियाँ उनके अपने नियंत्रण में रहें। मौजूदा इंटेंट-आधारित लेनदेन प्रोटोकॉल ने पहले ही इस पथ का कुछ भाग खोज लिया है, और उद्योग इसे पूरा करना जारी रख सकता है। [[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)

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

IBIT iShares का बिटकॉइन एक्सचेंज-ट्रेडेड उत्पाद है, और बाजार में जो ट्रेड होता है वह इसके शेयर हैं। इसकी व्यवस्था आंशिक अलगाव का एक उदाहरण प्रदान करती है: शेयर और अंतर्निहित बिटकॉइन अलग-अलग दर्ज किए जाते हैं, और Vault Balance (अभिरक्षा शेष) के लिए प्रासंगिक निजी कुंजियाँ कोल्ड स्टोरेज में रखी जाती हैं। शेयर ट्रेडिंग रिकॉर्ड में परिवर्तन के लिए यह आवश्यक नहीं है कि अंतर्निहित बिटकॉइन प्रत्येक लेनदेन के साथ स्थानांतरित हो। [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) इससे जो सीखा जा सकता है वह है ट्रेडिंग अधिकारों और आरक्षित निपटान अधिकारों का पृथक्करण। इसका Trading Balance (ट्रेडिंग सेवा शेष) की व्यवस्था भिन्न है, और अभिरक्षा स्वयं भी जोखिम वहन करती है; कोल्ड स्टोरेज को स्वतंत्र निर्देश और हस्ताक्षर सत्यापन के साथ जोड़ा जाना चाहिए।

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

V. विफलताओं को अलग करने और प्रतिस्थापनीयता संरक्षित रखने के लिए स्तरित आर्किटेक्चर का उपयोग करेंहमें ऐसे पहचान और प्राधिकरण इंटरफेस, परिसंपत्ति नीतियाँ और निपटान सत्यापन विधियाँ चाहिए जो स्वतंत्र रूप से विकसित हो सकें। विभिन्न चेन अपने स्वयं के निष्पादन मॉडल बनाए रख सकती हैं और स्पष्ट इंटरफेस के माध्यम से जुड़ सकती हैं। इंटरफेस को सुरक्षा गारंटी और उनकी शर्तें बतानी चाहिए, केवल यह नहीं कहना चाहिए कि "कॉल सफल रहा।" इंटरनेट अनुभव इस दृष्टिकोण का समर्थन करता है। RFC 9518, "केंद्रीकरण, विकेंद्रीकरण और इंटरनेट मानक" में, मार्क नॉटिंघम विशेष रूप से उन स्थितियों पर चर्चा करते हैं जिनमें केंद्रीकरण सहायक हो सकता है, और यह भी विश्लेषण करते हैं कि यह किस शक्ति और जोखिम को लाता है। [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) यह वास्तव में सीखने योग्य दृष्टिकोण है: आर्किटेक्चर को उत्तर देने दें कि कौन सी जिम्मेदारियाँ केंद्रीकृत की जा सकती हैं, किस हद तक, और उस शक्ति को फैलने से कैसे रोका जाए। एक सेवा को विसंगतियों की केंद्रीय रूप से पहचान करने की अनुमति दी जा सकती है जबकि परिसंपत्तियों को छूने की उसकी अनुमति सीमित हो; उपयोगकर्ताओं को अपनी परिसंपत्ति नीतियों और सत्यापन रिकॉर्ड खोए बिना सेवाएँ बदलने में सक्षम होना चाहिए।

सबसे महत्वपूर्ण स्वीकृति प्रश्न है: किसी व्यावसायिक सेवा के समझौता किए जाने के बाद, कौन सी स्वतंत्र परत अभी भी उसे अस्वीकार कर सकती है? यदि सभी परतें एक ही प्रशासनिक कुंजी साझा करती हैं, तो तथाकथित परतबंदी केवल परिनियोजन आरेख पर परतबंदी है।

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

इस लेख में प्रस्तावित लक्ष्य आर्किटेक्चर। निपटान परत को परिसंपत्ति नीति लागू करनी चाहिए; वॉलेट में संकेत इस बाधा को प्रतिस्थापित नहीं कर सकते। दैनिक हस्ताक्षर, नियम परिवर्तन और पुनर्प्राप्ति प्राधिकार को अलग किया जाना चाहिए और बायपास परीक्षण के अधीन किया जाना चाहिए।

6. उपयोगकर्ताओं को अपनी परिसंपत्तियों को हल्के ढंग से सत्यापित करने दें

आम लोगों को अपने स्वयं के बैलेंस और रसीदें सत्यापित करने के लिए पूरी चेन का संपूर्ण इतिहास संग्रहीत और निष्पादित नहीं करना पड़े; न ही उन्हें वॉलेट के पीछे के केवल एक सर्वर पर भरोसा करना पड़े। सातोशी नाकामोतो ने पहले ही श्वेतपत्र के खंड 8 में SPV, सरलीकृत भुगतान सत्यापन प्रस्तावित किया था। बिटकॉइन का BIP-157 क्लाइंट को फ़िल्टर डाउनलोड करने और अपने से संबंधित ब्लॉक खोजने देने की खोज जारी रखता है; एथेरियम में भी लाइट क्लाइंट डिज़ाइन हैं। [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) तो समस्या यह नहीं है कि किसी ने इसके बारे में सोचा नहीं, बल्कि यह है कि हमें अभी भी स्पष्ट सुरक्षा शर्तों के साथ सत्यापन क्षमता को उन वॉलेट में बनाना है जिन्हें उपयोगकर्ता प्रतिदिन उपयोग करते हैं।ऐसे चेन का उदाहरण लें जो अकाउंट स्टेट प्रूफ़ का समर्थन करती है: बैलेंस क्वेरी करते समय, सर्वर को बैलेंस और एक प्रूफ़ दोनों लौटाने चाहिए। वॉलेट पहले उस चेन के नियमों के अनुसार एक छोटे ब्लॉक डाइजेस्ट, यानी ब्लॉक हेडर, को सत्यापित करता है, और फिर जाँचता है कि यह बैलेंस उस डाइजेस्ट द्वारा प्रतिबद्ध डेटा के अनुरूप है या नहीं। सर्वर उत्तर देता है, और वॉलेट उत्तर को सत्यापित कर सकता है। बिटकॉइन का SPV इस बात का प्रमाण सत्यापित करता है कि संबंधित लेनदेन शामिल किए गए थे; इसे सीधे बैलेंस प्रूफ़ के रूप में नहीं कॉपी किया जा सकता। वॉलेट को यह भी स्पष्ट रूप से दिखाना चाहिए कि वह कहाँ तक सिंक हुआ है और कौन-सी जानकारी सत्यापित की गई है; जब प्रूफ़ अनुपस्थित हों, डेटा पुराना हो, या स्रोत परस्पर विरोधी हों, तो उसे चेतावनी देनी चाहिए या इस जानकारी पर निर्भर उच्च-जोखिम वाले संचालन को रोकना चाहिए, और चुपचाप अंधविश्वास पर वापस नहीं गिरना चाहिए।

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

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

7. विसंगति पहचान और सुरक्षा सत्यापन को सार्वजनिक अवसंरचना के रूप में बनाएँ

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

साथ ही, हमें आक्रमण मामलों, अनुमति परीक्षणों और बार-बार चलाए जा सकने वाले सत्यापन उपकरणों को संयुक्त रूप से बनाए रखना होगा। विनिर्देशों को साझा करके तथा स्वतंत्र कार्यान्वयन और स्वतंत्र सत्यापन को संरक्षित रखकर ही कॉमन-मोड विफलताओं को कम किया जा सकता है। फ़ाउंडेशनों और एक्सचेंजों के पास पहले से सुरक्षा निवेश हैं, जैसे एथेरियम फ़ाउंडेशन की Trillion Dollar Security Initiative। [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) अगला प्रश्न यह पूछना है कि क्या इस निवेश को ऐसी सार्वजनिक अवसंरचना में बदला जा सकता है जिसे अन्य टीमें भी अपना और जाँच सकें।इन सात कार्य मदों में से कोई भी पूर्ण सुरक्षा की गारंटी नहीं दे सकता। उन्हें जो प्रदान करना है वह है निरीक्षण योग्य सीमाएँ: अनुमति समझौते की किन परिस्थितियों में, अधिकतम कितनी संपत्ति उजागर होती है, विसंगतियों का कितनी जल्दी पता लगाया जा सकता है, और रिकवरी अभी भी किस पर निर्भर है।

इस बिंदु पर, कुछ लोग कह सकते हैं: दिशा सही लगती है, लेकिन उद्योग पहले से ही इतने वर्षों से चल रहा है; पुनर्निर्माण में कितने लोग और कितना समय लगेगा? क्या यह अभी भी आदर्शवाद नहीं है?

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

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

Anthropic और PNNL के शोध एक ठोस उदाहरण देते हैं: एक सीमित महत्वपूर्ण अवसंरचना सिमुलेशन वातावरण में, शोधकर्ताओं ने बताया कि हमले का पुनर्निर्माण संभवतः कई हफ्तों से घटाकर लगभग तीन घंटे कर दिया गया। [[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) यह साबित नहीं कर सकता कि एक छोटी टीम पहले से ही पूरे उद्योग को सुरक्षित रूप से फिर से लिख सकती है, लेकिन यह दिखाता है कि पहले महँगे सत्यापन और आक्रमण-रक्षा कार्यों की नई लागत स्थितियाँ हो सकती हैं।

एक संगठनात्मक दृष्टिकोण जो अभी शुरू किया जा सकता है, वह है संयुक्त रूप से एक Build in Public AI Factory का निर्माण करना। उद्योग विशेषज्ञ, विद्वान और व्यवसायी खुले तौर पर आवश्यकताएँ और स्वीकृति विनिर्देश (spec) लिखते हैं, यह समझाते हुए कि क्या संरक्षित करना है, कौन से संचालन की अनुमति है, और किन अनुमतियों के समझौते के बाद कौन सी सीमाएँ अभी भी बनी रहनी चाहिए, और फिर इन आवश्यकताओं को स्वीकृति परीक्षणों में बदलते हैं। कोडिंग एजेंटों के समूह मुख्य कोडिंग, परीक्षण और डिबगिंग कार्य करते हैं; विभिन्न टीमें डिज़ाइन और परिणामों का निरीक्षण करती हैं, और मनुष्य निर्णय और स्वीकृति की जिम्मेदारी वहन करते हैं।प्रतिभागी विचार, मशीनें, कंप्यूटिंग शक्ति और मॉडल इनवोकेशन कोटा, यानी AI टोकन, का योगदान कर सकते हैं। AI और क्लाउड कंप्यूटिंग कंपनियाँ भी मॉडल कोटा, कंप्यूटिंग संसाधनों और टूल्स के माध्यम से इस सार्वजनिक निर्माण का समर्थन कर सकती हैं। स्पेक्स, प्रोटोटाइप कोड, एजेंट वर्कफ़्लो, टेस्ट एनवायरनमेंट और सत्यापन परिणाम सभी सामान्य रूप से अनुरक्षित अवसंरचना बन सकते हैं, जिससे अगली टीम सीधे वहीं से आगे बढ़ सके। लक्ष्य विकास क्षमता को पुनः प्रयोग योग्य सार्वजनिक सुविधाओं में निर्मित करना और किसी एक व्यक्ति के समय या किसी एक टीम पर निर्भरता कम करना है।

हमलावर भी AI का उपयोग कर रहे हैं, और अब हमारे पास रक्षा को अतीत की उत्पादन विधियों में छोड़ने का कोई कारण नहीं है। [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) लेकिन कोड जनरेशन का तेज़ होना केवल प्रारंभिक बिंदु है। केवल बाधाओं को स्पष्ट रूप से लिखकर, परीक्षणों को बार-बार चलाने योग्य बनाकर, और किसी घटक को निरीक्षण योग्य और प्रतिस्थापन योग्य बनाकर ही AI क्षमता को अवसंरचना सुधार में परिवर्तित किया जा सकता है।

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

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

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

हमें मिलकर इस प्रकार की अवसंरचना का निर्माण करना चाहिए जहाँ, भले ही किसी भाग से समझौता हो गया हो, परिसंपत्तियों की सीमाएँ अभी भी बनी रहें, अन्य सिस्टम अभी भी त्रुटियों को अस्वीकार कर सकें, और उपयोगकर्ताओं के पास पुनर्प्राप्ति और निकास के मार्ग अभी भी हों। स्टार वॉर्स से नाम उधार लेते हुए, यह हमारी A New Hope है। [[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) आशा सामान्य निर्माताओं से आती है जो कार्य करने को तैयार हैं, और इस क्षण से भी जब कोडिंग एजेंट और नई इंजीनियरिंग विधियाँ उन्हें अधिक निर्माण कार्य करने में सक्षम बनाती हैं।मैं Ethereum, Solana, Bitcoin और XRP Ledger जैसे प्रोजेक्ट्स के बिल्डर्स, Binance, Coinbase और Kraken जैसे एक्सचेंजों, तथा वॉलेट, प्रोटोकॉल, सुरक्षा अनुसंधान, AI और क्लाउड कंप्यूटिंग टीमों को आमंत्रण देना चाहता हूँ: एक स्पष्ट रूप से परिभाषित पायलट से शुरू करें और मिलकर ऐसे सुधार तैयार करें जिन्हें अन्य टीमें अपना और परख सकें।

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

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

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

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

जो भाग लेने को इच्छुक हैं, उनका स्वागत है कि वे X पर इस पहल को सार्वजनिक रूप से रीपोस्ट या कोट करें और @mave99a को टैग करें, तथा उस समस्या के बारे में बात करें जिसे आप हल करना चाहते हैं, डी-सेंसिटाइज़्ड हमला मामलों, या उन संसाधनों के बारे में जो आप योगदान कर सकते हैं। मैं चाहता हूँ कि चर्चा सार्वजनिक रूप से आगे बढ़े, ताकि अधिक बिल्डर्स इसे देख सकें और जुड़ सकें।

क्रिप्टो इस तरह नहीं चल सकता। जो मिलकर काम करने को तैयार हैं, आइए अब कार्रवाई करें, एक ऐसे सुधार से शुरुआत करें जिसे बनाया जा सके और जो परीक्षण का सामना कर सके।बाइनेंस, प्रारंभिक घोषणा आधिकारिक पोस्ट और अनुवर्ती जाँच आधिकारिक अपडेट, 2026-10-30; TRM मल्टी-चेन विश्लेषण। यह मसौदा 2026-10-30 तक सत्यापित किया गया था; जाँच और रिकवरी की स्थिति बदल सकती है। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)

सातोशी नाकामोतो, बिटकॉइन: एक पीयर-टू-पीयर इलेक्ट्रॉनिक कैश सिस्टम, 2008। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)

यूनिस्वैप, यूनिचेन EVM समतुल्यता। साझा निर्भरताओं की जोखिम सांद्रता इस लेख में लेखक का निर्णय है, उस दस्तावेज़ का निष्कर्ष नहीं। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)

विटालिक बुटेरिन, सैम विल्सन, आन्सगर डाइट्रिच्स, लाइटक्लाइंट, EIP-7702: EOAs के लिए कोड सेट करें, निर्मित 2024-05-07। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)

मिनफेंग क्यूई, किन वांग, रुईकियांग ली, तियानकिंग झू, शिपिंग चेन, EIP-7702 फिशिंग अटैक, 2025-12-13, arXiv v1 प्रीप्रिंट; यह इस बाइनेंस घटना की पहचान नहीं है। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)

एथेरियम, अधिकतम निकालने योग्य मूल्य (MEV), ऑर्डरिंग तंत्र, विभिन्न प्रकार, और नकारात्मक प्रभाव; "इसे एक बग के रूप में ठीक किया जाना चाहिए" उपयोगकर्ताओं को नुकसान पहुँचाने वाले व्यवहार के प्रति लेखक का इंजीनियरिंग रुख है। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)

PHP आधिकारिक 2026 समाचार संग्रह; CISA 2026-10-26 ज्ञात शोषित भेद्यताएँ अपडेट, CVE-2026-109618, CVE-2026-109619। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)

सेफ, गार्ड्स और मॉड्यूल, कार्यक्षमता और अनुमति जोखिमों का विवरण। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)

एप्पल, एप्पल उपयोग किए गए असली पुर्जों के समर्थन के साथ मरम्मत विकल्पों का विस्तार करेगा, 2024-04-11; वर्तमान पुर्जों की पेयरिंग समर्थन विवरण। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)लेजर, हार्डवेयर इम्प्लांट हमले पर लेजर की प्रतिक्रिया, 2026-10, वितरण श्रृंखला में एक हमले पर विक्रेता का बयान; जो ग्रैंड, हार्डवेयर इम्प्लांट पर रिवर्स इंजीनियरिंग शोध। असत्यापित नेटवर्क हानि अनुमानों को निश्चित निष्कर्ष के रूप में प्रस्तुत न करें। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)

कॉइनकाइट, वर्तमान COLDCARD सुरक्षा स्थिति, 2026-10-30 को एक्सेस किया गया, जुलाई 2026 की घटना और उपचार का निरंतर अद्यतन रिकॉर्ड; अपग्रेड करना और सीड माइग्रेशन दो अलग-अलग ऑपरेशन हैं। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)

ERC-4337: ऑल्ट मेमपूल का उपयोग करते हुए अकाउंट एब्स्ट्रैक्शन; ट्रेज़र, SLIP39 FAQs, थ्रेशोल्ड रिकवरी, संगतता, और अतिरिक्त पासफ्रेज़ जोखिम। मौजूदा तंत्र निर्माण के लिए एक आधार हैं, और इसका मतलब यह नहीं है कि हर परिनियोजन विश्वसनीय है। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-walletstandards)BIP-174: आंशिक रूप से हस्ताक्षरित बिटकॉइन लेनदेन प्रारूप, अहस्ताक्षरित लेनदेन के लिए एक विनिमय प्रारूप, क्रॉस-चेन सामान्य परिसंपत्ति रणनीति विनिर्देश नहीं। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-psbt)

W3C, सत्यापन योग्य क्रेडेंशियल्स अवलोकन v1.0, 2026-07-30 समूह नोट; एथेरियम गोपनीयता नोट्स। अवलोकन में वर्णित प्रौद्योगिकियों की मानक स्थिति प्रत्येक मामले में स्वतंत्र है। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)

CoW प्रोटोकॉल दस्तावेज़ीकरण, लेनदेन इरादे और सॉल्वर तंत्र; यह लेख किसी विशिष्ट परिनियोजन के लिए व्यापक सुरक्षा समर्थन प्रदान नहीं करता है। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-routing)

iShares, IBIT 2025 वार्षिक रिपोर्ट, PDF पृष्ठ 8–10 अभिरक्षा व्यवस्था और पृष्ठ 45 जोखिम प्रकटीकरण। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)

Mark Nottingham, RFC 9518: केंद्रीकरण, विकेंद्रीकरण, और इंटरनेट मानक, 2023-12, स्वतंत्र रूप से प्रस्तुत, सूचनात्मक RFC, मानक-ट्रैक विनिर्देश नहीं। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)

बिटकॉइन श्वेतपत्र अनुभाग 8 सरलीकृत भुगतान सत्यापन; BIP-157: क्लाइंट साइड ब्लॉक फ़िल्टरिंग; एथेरियम, लाइट क्लाइंट्स। विभिन्न लाइट क्लाइंट्स के सत्यापन दायरे और विश्वास शर्तें भिन्न होती हैं। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)

एथेरियम फाउंडेशन, ट्रिलियन डॉलर सिक्योरिटी इनिशिएटिव की घोषणा, 2025-05-14। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)

Anthropic, महत्वपूर्ण अवसंरचना की रक्षा के लिए AI, 2026-01-08, PNNL के सहयोग से सीमित-पर्यावरण अनुसंधान। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)

Anthropic, AI-सक्षम साइबर खतरों का मानचित्रण, वास्तविक दुरुपयोग नमूनों पर अनुसंधान। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)

Lucasfilm, स्टार वॉर्स: ए न्यू होप (एपिसोड IV), 1977; यह लेख शीर्षक और संयुक्त आत्म-बचाव की छवि उधार लेता है। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)