کریپتو نمی‌تواند به این شکل ادامه دهد: یک ابتکار خودنجات‌بخشی صنعتی از سوی یک فعال حوزه بلاکچین

یک حادثه نه‌تنها دارایی‌ها، بلکه اعتماد را نیز از بین می‌برد. کریپتو نمی‌تواند به این شکل ادامه دهد؛ ما باید خودمان را نجات دهیم.

نویسنده: رابرت مائو، بنیان‌گذار و مدیرعامل ArcBlock

این مقاله مجاز است که هر کسی آزادانه آن را بازتولید و بازنشر کند، به این امید که افراد بیشتری این فراخوان برای نجات صنعت توسط خودش را ببینند.

کریپتو نمی‌تواند به این شکل ادامه دهد. بارها و بارها، سرقت‌های گسترده نه تنها دارایی‌ها، بلکه اعتماد مشارکت‌کنندگان به کل صنعت را از بین می‌برند. ما باید خودمان را نجات دهیم.

در ۲۹ اکتبر ۲۰۲۶، یک حادثه امنیتی بزرگ در Binance رخ داد. اطلاعیه اولیه آن تخمین زد که حدود ۶.۳ میلیارد دلار دارایی تحت تأثیر قرار گرفته است، و حدود ۳ میلیارد دلار از دارایی‌های تحت تأثیر قرار گرفته مسدود شده بودند؛ تحقیقات در ابتدا به لپ‌تاپ یک مهندس DevOps اشاره کرد، و متعاقباً نقاط نفوذ احتمالی دیگری نیز کشف شد. Binance همچنین اعلام کرد که هیچ مدرکی دال بر نشت کلید خصوصی کیف پول یافت نشده است. مبلغ تحت تأثیر، ضرر خالص نهایی نیست، و زنجیره کامل حمله همچنان تحت investigation است. [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)

این ابتکار خطاب به سازندگان پروژه‌های بلاکچین مانند Ethereum و Solana، و همچنین به Binance، Coinbase، Kraken، و تمام صرافی‌ها، کیف پول‌ها، پروتکل‌ها، و سازندگان امنیتی که مایل به مشارکت هستند: بیایید با هم بنیاد حفاظت از دارایی‌ها را بازسازی کنیم. من مایلم مشارکت کنم، و امیدوارم افراد بیشتری با هم اقدام کنند.

این در حال حاضر به اندازه کافی سنگین است. اما آنچه بیشتر مرا نگران می‌کند این است که این حادثه چه مقدار اعتماد به کریپتو را از بین خواهد برد، و چه تعداد مهاجم را به این سوق خواهد داد که این صنعت را هدفی بدانند که هنوز ارزش ادامه حمله را دارد. حتی اگر کسی در نهایت متحمل ضررها شود، غرامت نمی‌تواند به طور خودکار اعتماد کاربران را ترمیم کند، و نه می‌تواند مانع از تکرار همان نوع تخریب شود.

Binance تنها نقطه ورودی است که ما را امروز مجبور به رویارویی با مشکل می‌کند. با نگاه به گذشته، صرافی‌ها، پل‌ها، پروتکل‌های روی زنجیره، و کیف پول‌ها مدت‌هاست دنباله‌ای طولانی از زخم‌ها بر جای گذاشته‌اند. شبکه‌ها و محصولات جدید مدام ظاهر می‌شوند، با این حال الگوهای شکست قدیمی بارها و بارها تکرار می‌شوند. ما نمی‌توانیم یک اطلاعیه صادر کنیم، مدتی صبر کنیم، و سپس حادثه بعدی را به عنوان امری عادی تلقی کنیم.

ما همچنین باید بپذیریم که کلاهبرداری‌ها و رویه صرفاً خلق مفاهیم بدون پذیرش مسئولیت ساخت، برای مدت طولانی به این صنعت آسیب رسانده‌اند. تیم‌هایی که به طور جدی فناوری و زیرساخت می‌سازند نیز باید پیامدهای اعتماد از دست رفته را با هم متحمل شوند. تا زمانی که مردم تمام کریپتو را به عنوان کلاهبرداری ببینند، فناوری و کاوشی که واقعاً ارزش حفظ کردن را دارند نیز ممکن است همراه با آن رها شوند.

به عنوان بنیان‌گذار ArcBlock و یک فعال در کریپتو و بلاکچین، من حاضر نیستم چنین نتیجه‌ای را بپذیرم. من معتقدم این صنعت ارزشی دارد که ارزش محافظت را دارد، و همچنین معتقدم که ما باید مسئولیت بنیاد امنیتی خودمان را بپذیریم. اگر به انتظار منفعلانه برای حادثه بعدی ادامه دهیم، خونریزی مکرر ممکن است در نهایت همه چیزهایی را که با هم ساخته‌ایم نابود کند.بنابراین، می‌خواهم این ابتکار را مطرح کنم: سازندگان صرافی‌ها، کیف‌پول‌ها و بلاک‌چین‌ها باید به‌طور مشترک زیربنای کنترل دارایی و تأیید امنیتی را بازسازی کنند تا دامنه آسیب ناشی از یک نفوذ واحد محدود شود. جدول زمانی زیر توضیح می‌دهد چرا تغییر ضروری است؛ پیشنهاد فنی که در ادامه می‌آید کاری است که معتقدم می‌توانیم آغاز کنیم.

در سال ۲۰۰۸، ساتوشی ناکاموتو یک سیستم پول الکترونیکی همتا به همتا پیشنهاد کرد و تلاش کرد پرداخت‌ها را کمتر به واسطه‌های مورد اعتماد وابسته کند. [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) با این حال، حوادث بزرگ از آن زمان تاکنون بارها مشکل تمرکز دوباره وجوه، مجوزها و وابستگی‌های نرم‌افزاری را آشکار کرده‌اند.

در زیر فهرستی زمانی از حوادث نماینده در حوزه‌هایی مانند صرافی‌های متمرکز (CEX)، صرافی‌های غیرمتمرکز (DEX)، پل‌ها و کیف‌پول‌ها آمده است. این فهرست یک پایگاه داده کامل حوادث نیست و نه آمار زیان سال‌به‌سال است. در جاهایی که مبالغ ذکر شده‌اند، به تأثیر ناخالص تقریبی در زمان وقوع حادثه اشاره دارند؛ سرقت، مسدودسازی و بازیابی بعدی به‌طور جداگانه توصیف می‌شوند و نمی‌توان آن‌ها را به‌عنوان زیان دائمی با هم جمع کرد.

۲۰۰۸ · وایت‌پیپر بیت‌کوین

نقطه شروع

وایت‌پیپر بیت‌کوین پرداخت‌های همتا به همتا بدون نهادهای مالی به‌عنوان واسطه را پیشنهاد کرد.

منبع

۲۰۱۱–۲۰۱۴ · سرقت بلندمدت Mt. Gox

CEX

Mt. Gox دچار سرقت بلندمدت شد و در نهایت عملیات خود را متوقف کرد. کیفرخواست بعدی وزارت دادگستری ایالات متحده ادعا کرد که حدود ۶۴۷٬۰۰۰ BTC بین سال‌های ۲۰۱۱ و ۲۰۱۴ به سرقت رفته است. این یک حمله یک‌روزه در سال ۲۰۱۴ نبود.

منبع

۲۰۱۲ · Bitcoinica و Bitfloor

CEX / زیرساخت امانی

محیط میزبانی Linode متعلق به Bitcoinica compromised شد؛ در همان سال، پشتیبان‌گیری رمزنگاری‌نشده کیف‌پول Bitfloor به نقطه ورود حمله تبدیل شد. سرورها و پشتیبان‌های پشت پلتفرم نیز بخشی از مرز امنیت دارایی هستند.

منبع

۲۰۱۵ · کیف‌پول گرم Bitstamp

CEX

کیف‌پول گرم Bitstamp compromised شد و محیط عملیاتی متعاقباً بازسازی شد. تفکیک رسمی بین دامنه حادثه و ذخایر آفلاین نشان داد که جداسازی می‌تواند دامنه مواجهه را محدود کند.

منبع

۲۰۱۶ · Bitfinex

CEX

حدود ۱۲۰٬۰۰۰ BTC از Bitfinex به سرقت رفت. ترتیبات چندامضایی همچنان نیازمند مجوزدهی و تأیید مستقل سرتاسری است.

منبع ۱ · منبع ۲

۲۰۱۶ · The DAO

پروتکل روی زنجیره

قرارداد The DAO دچار حمله بازگشت مجدد (reentrancy) شد و حدود ۳.۶ میلیون ETH به یک زیر-DAO منتقل شد و متعاقباً یک فورک اتریوم را برانگیخت. یک مسیر اجرای مشروع می‌تواند نتایج تجاری فاجعه‌باری تولید کند.

منبع ۱ · منبع ۲

۲۰۱۷ · کتابخانه کیف‌پول اشتراکی Parity

کیف‌پول قراردادی

کتابخانه کیف‌پول اشتراکی Parity نابود شد و حدود ۵۱۳٬۰۰۰ ETH مسدود شد. حتی اگر منتقل نشوند، وجوه می‌توانند به دلیل وابستگی‌های کد اشتراکی غیرقابل استفاده شوند.

منبع

۲۰۱۸ · Coincheck

CEXهات‌ولت NEM صرافی Coincheck به سرقت رفت. مرز میان ذخایر آفلاین، مجوزهای هات‌ولت و نیازهای تجاری بار دیگر به مسئله‌ای تبدیل شد.

منبع

۲۰۱۹ · Binance

CEX

Binance اعلام کرد که ۷,۰۰۰ BTC در یک تراکنش واحد برداشت شده است. خروج دارایی‌های در مقیاس بزرگ باید پیش از امضا محدود شود.

منبع

۲۰۲۰ · KuCoin

CEX

حادثه هات‌ولت KuCoin که متعاقباً حجم زیادی از دارایی‌ها از طریق همکاری چندجانبه بازیابی شد. مبلغ ناخالص سرقت‌شده و زیان نهایی یک عدد نیستند.

منبع

۲۰۲۱ · Poly Network

پروتکل بین‌زنجیره‌ای

حدود ۶۱۲ میلیون دلار دارایی از Poly Network خارج و سپس به‌صورت مرحله‌ای بازگردانده شد. مجوزدهی بین‌زنجیره‌ای و کنترل دارایی را نمی‌توان تنها از مسیرهای عادی تجاری حفظ کرد.

منبع

۲۰۲۲ · پل Ronin

پل

مجوزهای اعتبارسنج‌های Ronin به خطر افتاد و ۱۷۳,۶۰۰ ETH و ۲۵.۵ میلیون USDC خارج شد. کلیدهای چندین اعتبارسنج نیز می‌توانند در همان زنجیره حمله قرار گیرند.

منبع

۲۰۲۲ · کیف پول Slope

کیف پول

حادثه کیف پول Slope در اکوسیستم Solana. Solana رسماً اعلام کرد که اطلاعات کلید خصوصی به‌طور تصادفی به یک سرویس پایش برنامه ارسال شده است؛ این نقض اجماع Solana نبود.

منبع

۲۰۲۳ · Euler

پروتکل وام‌دهی

حدود ۱۹۷ میلیون دلار دارایی به دلیل یک آسیب‌پذیری پروتکل از Euler خارج و متعاقباً بازیابی شد. ترکیب‌های پیچیده در یک تراکنش واحد می‌توانند نقص‌های منطق تجاری را تشدید کنند.

منبع

۲۰۲۳ · Ledger Connect Kit

ابزار اتصال کیف پول

Ledger Connect Kit دچار حمله زنجیره تأمین شد و کد مخرب وارد فرانت‌اند برنامه شد. امنیت دستگاه سخت‌افزاری نمی‌تواند جایگزین تأیید محتوای تراکنش شود.

منبع

۲۰۲۴ · DMM Bitcoin

CEX

حدود ۳۰۸ میلیون دلار از DMM Bitcoin به سرقت رفت. FBI و سایر نهادها متعاقباً حملات مهندسی اجتماعی علیه پرسنل مرتبط و زنجیره امضا را افشا کردند.

منبع

۲۰۲۴ · Radiant Capital

پروتکل وام‌دهی / امضا

حدود ۵۰ میلیون دلار از Radiant Capital به سرقت رفت و چندین دستگاه توسعه‌دهنده به خطر افتاد. امضای چندجانبه همچنان می‌تواند به‌طور جمعی به اطلاعات تراکنش آلوده وابسته باشد.

منبع

۲۰۲۵ · Bybit / Safe

CEX / فرانت‌اند کیف پول

حادثه حدود ۱.۵ میلیارد دلاری Bybit شامل محیط توسعه‌دهنده و فرانت‌اند Safe بود و امضاکنندگان تراکنشی را تأیید کردند که منطق کنترل کیف پول را تغییر می‌داد.

منبع ۱ · منبع ۲

۲۰۲۵ · Cetus DEX

DEXحادثه حدود ۲۲۳ میلیون دلاری Cetus روی Sui، با اشاره پژوهشگران به نقصی در یک کتابخانه ریاضی. محیط‌های غیر EVM نیز به همین ترتیب باید کد و دامنه مواجهه دارایی خود را بررسی کنند.

منبع

۲۰۲۶-۰۷ · نقص اعداد تصادفی COLDCARD

کیف پول سخت‌افزاری / تولید seedیک نقص در فریم‌ور، تولید seed را تضعیف کرد و به مهاجمان اجازه داد در حالی که دستگاه آفلاین بود، کلیدهای خصوصی مرتبط را بازسازی کنند. ارتقا نمی‌تواند seedهای ضعیفی را که قبلاً تولید شده‌اند برطرف کند؛ مهاجرت مطابق با توصیه‌نامه هنوز لازم است.

منبع

۲۰۲۶-۱۰ · ایمپلنت سخت‌افزاری Ledger

حمله به کیف پول سخت‌افزاری / توزیع

Ledger تأیید کرد که دستگاه‌های اصلاح‌شده از طریق کانال‌های توزیع در جنوب شرق آسیا توزیع شده‌اند و اجزای ایمپلنت‌شده عبارت‌های بازیابی را در طول مقداردهی اولیه سرقت می‌کنند. این فروشنده می‌گوید تراشه‌ها، سیستم‌عامل و سرورهایش compromised نشده‌اند.

منبع

۲۰۲۶ · حادثه چندزنجیره‌ای Binance

CEX / چندزنجیره‌ای

Binance در ابتدا تخمین زد که تقریباً ۶.۳ میلیارد دلار دارایی تحت تأثیر قرار گرفته است و تحقیقات درباره سایر نقاط نفوذ احتمالی همچنان ادامه دارد. یک سیستم‌عامل واحد می‌تواند دارایی‌ها را به‌طور همزمان در چندین شبکه در معرض خطر قرار دهد.

منبع ۱ · منبع ۲ · منبع ۳

در اینجا CEXها وجود دارند، اما همچنین صرافی‌های غیرمتمرکز، پروتکل‌های وام‌دهی و پل‌ها؛ دارایی‌های سرقت‌شده و دارایی‌های مسدودشده وجود دارند. حملات در لایه‌های مختلف رخ می‌دهند و روش‌های رفع نیز متفاوت‌اند. من مخالف تقلیل همه این‌ها به یک جمله واحد «کاربران در محافظت از کلیدهای خصوصی خود شکست خوردند» هستم. چگونه کاربران می‌توانند بدانند که محیط توسعه یک ابزار خاص، یک کتابخانه مشترک خاص، یا یک مجوز غیرقابل‌فهم به نقطه ورود تمام دارایی‌هایشان تبدیل خواهد شد؟

شبکه‌های توزیع‌شده پیش از این کارهای زیادی انجام داده‌اند، با این حال جداسازی خطا برای کنترل دارایی هنوز بسیار ناکافی است. اجرای روی زنجیره یک تراکنش را صادقانه کامل می‌کند، اما نمی‌تواند به جای ما پاسخ دهد که چرا آن تراکنش حق جابه‌جایی این‌همه دارایی را دارد.

سهم اتریوم قابل توجه است. این شبکه افراد بیشتری را قادر ساخت تا برنامه‌های روی زنجیره بنویسند و مجموعه غنی‌ای از ابزارها و تجربه توسعه را پرورش داد. اما امروزه بسیاری از زنجیره‌های جدید و L2ها (شبکه‌های مقیاس‌پذیری لایه ۲) سازگاری با EVM را هدف اصلی خود می‌دانند. EVM، ماشین مجازی که قراردادهای هوشمند اتریوم را اجرا می‌کند، در حال تبدیل شدن به یک پیش‌فرض فنی است که به‌طور گسترده تکرار می‌شود. سازگاری واقعاً مهاجرت برنامه‌ها را راحت می‌کند؛ مستندات پروژه‌هایی مانند Unichain صراحتاً استفاده مجدد از ابزارهای اتریوم را به عنوان ارزش یک محیط اجرای معادل ذکر می‌کند. [[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 نسبت داد. ورود مجدد، به‌خطر افتادن سرویس‌های امضا، و دستکاری فرانت‌اند نیز آسیب‌پذیری یکسانی نیستند. اما چنین تمایزهایی نباید بهانه‌ای برای توقف زیر سؤال بردن معماری شوند: چرا لایه زیرین محدودیت‌های بیشتری که به‌راحتی قابل دور زدن نیستند را به نمایندگی از خطاهای لایه‌های بالایی حفظ نمی‌کند؟

MEV نیز مرا ناراضی می‌کند. این اصطلاح به فضایی اشاره دارد که در آن مشارکت‌کنندگان از طریق گنجاندن، حذف و ترتیب‌دهی تراکنش‌ها ارزش اضافی به دست می‌آورند. به نظر من، استفاده از قدرت ترتیب‌دهی برای ساندویچ کردن تراکنش‌های کاربر و بدتر کردن نتایج اجرای آن‌ها باید به‌عنوان یک باگ که نیاز به رفع دارد تلقی شود، نه به‌عنوان یک ویژگی ارزشمند برای حفظ، فقط به این دلیل که کسی می‌تواند از آن سود ببرد. مستندات خود اتریوم نیز صراحتاً به آسیب ساندویچ تراکنش‌ها به کاربران و خطر MEV برای پایداری شبکه اذعان دارد. [[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEV منحصر به اتریوم نیست و فعالیت‌های متفاوتی مانند آربیتراژ و لیکوییدیشن را نیز شامل می‌شود؛ صنعت در حال حاضر تحقیقات کاهش اثر را دارد. نقد من این است که انگیزه حفظ شبکه نمی‌تواند دلیلی برای قربانی کردن شرایط تراکنش کاربران شود. یک سیستم تراکنش بهتر باید حداقل نتیجه تحویل و کارمزدهای مجاز را در مجوز بنویسد و فضای سفارش‌دهندگان برای استفاده از اطلاعات پرنشده به‌منظور آسیب رساندن به کاربران را محدود کند.من همیشه احساس کرده‌ام که تأثیر اتریوم بر کریپتو تا حدی شبیه تأثیر PHP بر اینترنت است: به بسیاری از افراد امکان ساخت چیزها را داد، و همچنین بدهی مهندسی برجای گذاشت که بازپرداخت آن زمان زیادی خواهد برد. PHP هنوز در اکتبر ۲۰۲۶ نیاز داشت یک آسیب‌پذیری شدید اجرای کد از راه دور را برطرف کند. بلوغ و محبوبیت نمی‌توانند جای سخت‌سازی مستمر را بگیرند. [[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) ما باید این را به یک قابلیت بنیادین با پذیرش آسان‌تر تبدیل کنیم که تمام مسیرهای کنترل دارایی را پوشش دهد. اگر تنها انتقال‌های مستقیم محدود شوند در حالی که دور زدن از طریق تأییدهای نامحدود، ماژول‌ها یا ارتقاها مجاز باشد، حفاظت شکست خواهد خورد. اینکه آیا قرارداد لیست سفید قابل ارتقا است و آیا مجوزهای گیرنده تغییر کرده‌اند نیز باید وارد دامنه بررسی شود. قفل فعال‌سازی اپل الهام‌بخش زندگی روزمره است: این قفل فعال‌سازی مجدد دستگاه‌های دزدیده‌شده را محدود می‌کند و کالیبراسیون برخی قطعات دزدیده‌شده را محدود می‌سازد، با هدف کاهش ارزشی که می‌تواند پس از سرقت مورد بهره‌برداری قرار گیرد. [[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) کیف پول‌ها نیز ارزش طراحی در این جهت را دارند. اگر مهاجم کلیدی را به دست آورد، دامنه دارایی‌هایی که می‌تواند نقد کند همچنان محدود می‌ماند و بازده مورد انتظار از حمله ممکن است کاهش یابد؛ خطراتی مانند اختلال در سرویس‌ها همچنان باید به‌طور جداگانه مدیریت شوند.

این همان چیزی است که من «قانون اساسی» امنیت دارایی می‌نامم: اختیار عملیاتی ممکن است به خطر بیفتد، اما اختیار اصلاح مرزها باید مستقل باقی بماند. فرآیندهای بازیابی نیز باید محدود شوند تا از قفل شدن دائمی دارایی‌ها به‌دلیل یک پیکربندی نادرست واحد جلوگیری شود.

II. کیف پول‌ها را وادار کنید مسئولیت امنیتی را بپذیرند، نه اینکه صرفاً عبارت‌های یادیار را تحویل دهند

من نارضایتی شدیدی از سیستم‌های کیف پول امروزی دارم: اگر محصولی از یک فرد عادی بخواهد مجموعه‌ای از کلمات را رونویسی کند، مطالبه کند که هرگز آنها را افشا، گم یا فریب نخورد و سپس تمام شکست‌های بعدی را به مسئولیت کاربر نسبت دهد، من این را طراحی غیرمسئولانه می‌دانم. خودحضانتی باید به مردم کنترل بدهد و همچنین باید به آن‌ها قابلیت‌های حفاظت و بازیابی قابل استفاده بدهد. نباید از هر کاربر بخواهد که ابتدا به یک متخصص امنیت تبدیل شود. این نیز آستانه‌ای است که کریپتو برای رسیدن به کاربران عادی بیشتر باید از آن عبور کند.رخدادهای اخیر این مشکل را کاملاً روی میز گذاشته‌اند. در اکتبر ۲۰۲۶، Ledger تأیید کرد که مهاجمان دستگاه‌های اصل را دستکاری کرده و سپس آن‌ها را از طریق کانال‌های توزیع در جنوب شرق آسیا به بازار بازگردانده‌اند، و قطعات کارگذاشته‌شده در هنگام راه‌اندازی اولیه عبارت‌های بازیابی را می‌دزدیدند. Ledger این را یک حمله توزیع محلی پس از خروج دستگاه از کارخانه تعریف کرد، نه نفوذ به تراشه، سیستم‌عامل یا سرورهای آن. [[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) حادثه ژوئیه COLDCARD شامل تضعیف تولید seed توسط فریم‌ور بود: دستگاه نیازی به کنترل از راه دور نداشت تا مهاجم بتواند کلیدهای خصوصی مربوطه را بازسازی کند. به‌روزرسانی فریم‌ور فرایند تولید را برای آینده اصلاح می‌کند، اما seedهای ضعیفی که قبلاً تولید شده‌اند هنوز نیاز به مهاجرت دارند. [[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 است و آنچه در بازار معامله می‌شود سهام آن است. ترتیبات آن نمونه‌ای از جداسازی جزئی ارائه می‌دهد: سهام و بیت‌کوین پایه به‌صورت جداگانه ثبت می‌شوند و کلیدهای خصوصی مربوط به موجودی خزانه (موجودی حضانت) در ذخیره سرد نگهداری می‌شوند. تغییرات در سابقه معاملات سهام نیازی به جابه‌جایی بیت‌کوین پایه با هر تراکنش ندارد. [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) آنچه می‌توان از این آموخت، جداسازی حقوق معاملاتی و حقوق تصرف ذخیره است. موجودی معاملاتی آن (موجودی سرویس معاملاتی) ترتیبات متفاوتی دارد و خود حضانت نیز خطراتی به همراه دارد؛ ذخیره سرد باید با دستورالعمل مستقل و تأیید امضا همراه باشد.

من نقطه ورود معاملاتی را به روتر تشبیه می‌کنم به این امید که بتوان آن را بدون حمل کلید اصلی بر تمام دارایی‌های کاربران جایگزین کرد. تسویه پیچیده‌تر از ارسال بسته است و تحویل دارایی و مجوزدهی هنوز نیازمند تأیید مستقل هستند. غیرحضانتی کردن یک سرویس و سپس اعطای حق برداشت نامحدود به آن، تنها ریسک متمرکز را بازمی‌گرداند.

V. از معماری لایه‌ای برای جداسازی خطاها و حفظ قابلیت جایگزینی استفاده کنیدما به رابط‌های هویت و مجوز، سیاست‌های دارایی، و روش‌های تأیید تسویه نیاز داریم که بتوانند به‌طور مستقل تکامل یابند. زنجیره‌های مختلف می‌توانند مدل‌های اجرایی خود را حفظ کنند و از طریق رابط‌های شفاف به هم متصل شوند. رابط‌ها باید تضمین‌های امنیتی و شرایط آن‌ها را بیان کنند، نه اینکه صرفاً بگویند «فراخوانی موفق شد.» تجربه اینترنت از این رویکرد پشتیبانی می‌کند. در RFC 9518، «تمرکزگرایی، تمرکززدایی، و استانداردهای اینترنت»، مارک ناتینگهام به‌طور مشخص موقعیت‌هایی را بررسی می‌کند که در آن‌ها تمرکزگرایی می‌تواند مفید باشد، و همچنین قدرت و خطراتی را که به همراه می‌آورد تحلیل می‌کند. [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) این دقیقاً نگرشی است که ارزش آموختن دارد: بگذارید معماری پاسخ دهد که کدام مسئولیت‌ها می‌توانند متمرکز شوند، تا چه حد، و چگونه از گسترش آن قدرت جلوگیری شود. می‌توان به یک سرویس اجازه داد تا ناهنجاری‌ها را به‌صورت متمرکز شناسایی کند در حالی که اختیار آن برای دست زدن به دارایی‌ها محدود باشد؛ کاربران باید بتوانند بدون از دست دادن سیاست‌های دارایی و سوابق تأیید خود، سرویس‌ها را تغییر دهند.

مهم‌ترین پرسش پذیرش این است: پس از اینکه یک سرویس تجاری به خطر افتاد، کدام لایه مستقل هنوز می‌تواند آن را رد کند؟ اگر همه لایه‌ها یک کلید اداری مشترک داشته باشند، لایه‌بندی به‌اصطلاح فقط لایه‌بندی روی یک نمودار استقرار است.

این هدف را می‌توان به‌عنوان پنج لایه مسئولیت در نظر گرفت: سرویس تراکنش درخواست‌ها را ارسال می‌کند، کیف پول قصد کاربر را بیان می‌کند، سیاست مستقل اختیار بر نحوه تصرف دارایی را محدود می‌کند، مؤلفه تأیید عملیات و شواهد را بررسی می‌کند، و لایه تسویه محدودیت‌ها را اعمال و سوابق قابل تأیید ارائه می‌کند. آن‌ها می‌توانند توسط تیم‌های مختلف پیاده‌سازی شوند، و وابستگی‌ها و شرایط شکست آن‌ها نیز باید به‌طور جداگانه توصیف شوند.

معماری هدفی که این مقاله ترویج می‌کند. لایه تسویه باید سیاست دارایی را اعمال کند؛ اعلان‌های درون کیف پول نمی‌توانند جای این محدودیت را بگیرند. امضای روزانه، تغییرات قوانین، و اختیار بازیابی باید جدا شده و تحت آزمون دور زدن قرار گیرند.

6. بگذارید کاربران دارایی‌های خود را به‌صورت سبک تأیید کنند

مردم عادی نباید مجبور باشند کل تاریخچه کل زنجیره را ذخیره و اجرا کنند تا بتوانند موجودی‌ها و رسیدهای خود را تأیید کنند؛ و نباید مجبور باشند فقط به یک سرور واحد پشت کیف پول اعتماد کنند. ساتوشی ناکاموتو قبلاً SPV، تأیید ساده پرداخت، را در بخش ۸ وایت‌پیپر پیشنهاد کرد. BIP-157 بیت‌کوین به کاوش در این زمینه ادامه می‌دهد که به کلاینت‌ها اجازه دهد فیلترها را دانلود کنند و بلوک‌های مرتبط با خود را پیدا کنند؛ اتریوم نیز طرح‌های کلاینت سبک دارد. [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) بنابراین مشکل این نیست که هیچ‌کس هرگز به آن فکر نکرده است، بلکه این است که ما هنوز باید قابلیت تأیید با شرایط امنیتی شفاف را در کیف پول‌هایی که کاربران هر روز استفاده می‌کنند بسازیم.یک زنجیره را در نظر بگیرید که از اثبات‌های وضعیت حساب پشتیبانی می‌کند: هنگام استعلام یک موجودی، سرور باید هم موجودی و هم یک اثبات را بازگرداند. کیف پول ابتدا یک خلاصه بلوک کوتاه، یعنی سرآیند بلوک، را بر اساس قواعد آن زنجیره تأیید می‌کند و سپس بررسی می‌کند که آیا این موجودی با داده‌ای که خلاصه به آن متعهد شده سازگار است یا خیر. سرور پاسخ را ارائه می‌دهد و کیف پول می‌تواند پاسخ را تأیید کند. SPV بیت‌کوین گواهیِ گنجانده‌شدن تراکنش‌های مرتبط را تأیید می‌کند؛ نمی‌توان آن را مستقیماً به‌عنوان اثبات موجودی کپی کرد. کیف پول همچنین باید به‌وضوح نشان دهد که تا کجا همگام‌سازی کرده و کدام اطلاعات را تأیید کرده است؛ هنگامی که اثبات‌ها موجود نیستند، داده‌ها کهنه‌اند یا منابع با هم تعارض دارند، باید هشدار دهد یا عملیات پرخطری را که به این اطلاعات وابسته‌اند متوقف کند و هرگز نباید بی‌صدا به اعتماد کورکورانه عقب‌نشینی کند.

تأیید سبک همچنان شرایطی دارد. اثبات اینکه یک تراکنش در یک بلوک گنجانده شده است با خودآزماییِ معتبر بودن همه تراکنش‌های آن بلوک یکسان نیست. طرح‌های مختلف ممکن است به صادق بودن اکثریت توان هش یا به یک ثبت اولیه مورد اعتماد، یعنی یک نقطه بازرسی، تکیه کنند؛ آن‌ها همچنین باید در برابر سرورهایی که داده را بازداشت می‌کنند یا کاربران را روی یک ثبت زنجیره کهنه منزوی می‌سازند محافظت کنند. اینکه خودِ استعلام نشانی‌هایی را که کاربر به آن‌ها اهمیت می‌دهد افشا می‌کند نیز باید مدیریت شود. گره‌های کامل و تولیدکنندگان بلوک یک نقش نیستند؛ اتریوم امروز برای تولید بلوک از اعتبارسنج‌ها به‌جای ماینرها استفاده می‌کند.

مهم‌تر آنکه، اثبات اینکه «این انتقال واقعاً روی زنجیره رخ داده است» نمی‌تواند اثبات کند که «این دقیقاً همان انتقالی است که کاربر می‌خواست.» کلاینت‌های سبک نمی‌توانند جایگزین محدودیت‌های دارایی و بررسی‌های امضای پیشین شوند. آن‌ها به کاربران امکان می‌دهند کمتر به یک پاسخ غیرقابل‌تأیید تکیه کنند، در حالی که سیاست دارایی تضمین می‌کند حتی یک امضای معتبر نیز نتواند دارایی را بدون محدودیت تصرف کند. تنها با ساختن هر دو لایه با هم می‌توان قابلیت تأیید را میان مشارکت‌کنندگان توزیع کرد.

۷. شناسایی ناهنجاری و تأیید امنیتی را به‌عنوان زیرساخت عمومی بسازید

پیش از یک تراکنش، کسی باید بررسی کند که آیا عملیات با سیاست دارایی سازگار است و آیا به‌طور ناگهانی رفتار تاریخی را تغییر می‌دهد. ناهنجاری‌های آشکار می‌توانند باعث توقف یا بازبینی تشدیدشده شوند؛ گسترش مجوزها نیازمند یک مسیر مستقل دیگر است. هوش مصنوعی می‌تواند در داوری مشارکت کند، اما نباید مجوزی برای نادیده گرفتن قواعد سخت دریافت کند.

در همان زمان، باید به‌طور مشترک موارد حمله، آزمون‌های مجوز و ابزارهای تأیید قابل اجرای مکرر را نگهداری کنیم. تنها با به اشتراک گذاشتن مشخصات و حفظ پیاده‌سازی‌های مستقل و تأیید مستقل می‌توان شکست‌های حالت مشترک را کاهش داد. بنیادها و صرافی‌ها از قبل سرمایه‌گذاری‌های امنیتی دارند، مانند طرح امنیت تریلیون دلاری بنیاد اتریوم. [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) پرسش بعدی این است که آیا این سرمایه‌گذاری می‌تواند به زیرساخت عمومی تبدیل شود که تیم‌های دیگر نیز بتوانند آن را بپذیرند و بازرسی کنند.هیچ‌یک از این هفت قلم کار نمی‌تواند امنیت مطلق را تضمین کند. آنچه باید ارائه دهند مرزهای قابل بازرسی است: تحت چه شرایطی از به خطر افتادن مجوزها، حداکثر چه مقدار دارایی در معرض خطر قرار می‌گیرد، ناهنجاری‌ها با چه سرعتی قابل کشف هستند، و بازیابی هنوز به چه کسی وابسته است.

در این مرحله، ممکن است برخی بگویند: جهت درست به نظر می‌رسد، اما صنعت سال‌هاست که ادامه دارد؛ بازسازی چقدر نیروی انسانی و زمان می‌طلبد؟ آیا این هنوز آرمان‌گرایی نیست؟

اگر بر اساس شیوه گذشته تولید نرم‌افزار تخمین زده شود، این تردید بسیار واقع‌بینانه است. اما تا سال ۲۰۲۶، من معتقدم که عامل‌های کدنویسی و مهندسی نرم‌افزار توانمندشده با هوش مصنوعی ظرفیت ساخت و سازی را که می‌توانیم بسیج کنیم، تغییر داده‌اند. عامل‌های کدنویسی ذکرشده در اینجا دستیارهای برنامه‌نویسی هوش مصنوعی هستند که می‌توانند کد بخوانند و بنویسند، ابزارها را فراخوانی کنند، تست‌ها را اجرا کنند و بر اساس بازخورد در یک محیط توسعه به کار ادامه دهند. سازندگان اهداف را تعیین می‌کنند، مرزهای امنیتی را تعریف می‌کنند، از این ابزارها برای پیاده‌سازی و بررسی سیستم‌ها استفاده می‌کنند و مسئولیت نتایج را بر عهده می‌گیرند.

کاری که پیش‌تر نیازمند تیم‌های بزرگ برای پیاده‌سازی، تطبیق و نگهداری مکرر بود، اکنون می‌تواند توسط تیم‌های کوچک با این رویکرد مهندسی جدید آزمایش شود. یک تیم یک لایه را در دست می‌گیرد، اجزاء را حول رابط‌های مشخص تحویل می‌دهد، و سپس تیم‌های دیگر آن‌ها را بازرسی و ترکیب می‌کنند. سازماندهی قضاوت معماری انسانی، ظرفیت پیاده‌سازی عامل‌های کدنویسی، و راستی‌آزمایی امنیتی مستقل، به نظر من، مسیر ساخت و سازی است که ارزش ارزیابی جدی مجدد را دارد.

پژوهش Anthropic و PNNL یک مثال مشخص ارائه می‌دهد: در یک محیط شبیه‌سازی محدود زیرساخت حیاتی، پژوهشگران گزارش دادند که بازسازی حمله از احتمالاً چند هفته به حدود سه ساعت کاهش یافت. [[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) این نمی‌تواند ثابت کند که یک تیم کوچک هم‌اکنون می‌تواند با ایمنی کل صنعت را بازنویسی کند، اما نشان می‌دهد که کارهای پرهزینه پیشین راستی‌آزمایی و حمله-دفاع می‌توانند شرایط هزینه‌ای جدیدی داشته باشند.

یک رویکرد سازمانی که می‌توان همین حالا آغاز کرد، ساخت مشترک یک کارخانه هوش مصنوعی Build in Public است. متخصصان صنعت، دانشگاهیان و فعالان به‌صورت آشکار الزامات و مشخصات پذیرش (spec) را می‌نویسند، توضیح می‌دهند چه چیزی باید محافظت شود، کدام عملیات مجاز است، و پس از به خطر افتادن کدام مجوزها کدام مرزها باید همچنان برقرار بمانند، و سپس این الزامات را به تست‌های پذیرش تبدیل می‌کنند. گروه‌هایی از عامل‌های کدنویسی کار اصلی کدنویسی، تست و اشکال‌زدایی را بر عهده می‌گیرند؛ تیم‌های مختلف طراحی‌ها و نتایج را بازرسی می‌کنند، و انسان‌ها مسئولیت قضاوت و پذیرش را بر دوش می‌کشند.شرکت‌کنندگان می‌توانند ایده‌ها، ماشین‌ها، توان محاسباتی و سهمیه‌های فراخوانی مدل، یعنی توکن‌های هوش مصنوعی، را مشارکت دهند. شرکت‌های هوش مصنوعی و رایانش ابری نیز می‌توانند از این ساخت‌وساز عمومی از طریق سهمیه‌های مدل، منابع محاسباتی و ابزارها پشتیبانی کنند. مشخصات فنی، کد نمونه اولیه، گردش‌کارهای عامل، محیط‌های آزمون و نتایج راستی‌آزمایی همگی می‌توانند به زیرساختی تبدیل شوند که به‌طور مشترک نگهداری می‌شود و به تیم بعدی اجازه می‌دهد مستقیماً از همان‌جا ادامه دهد. هدف، تبدیل ظرفیت توسعه به تأسیسات عمومی قابل استفاده مجدد و کاهش وابستگی به زمان هر یک فرد یا هر یک تیم است.

مهاجمان نیز از هوش مصنوعی استفاده می‌کنند و دیگر دلیلی نداریم که دفاع را در روش‌های تولید گذشته رها کنیم. [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) اما سریع بودن تولید کد تنها نقطه شروع است. تنها با نوشتن صریح محدودیت‌ها، قابل اجرا کردن مکرر آزمون‌ها و قابل بازرسی و جایگزین‌پذیر کردن یک مؤلفه می‌توان توانایی هوش مصنوعی را به بهبود زیرساخت تبدیل کرد.

سازندگان مستقل با کمک عامل‌های کدنویسی و ابزارهای هوش مصنوعی با هم همکاری می‌کنند. کارگاه فضایی استعاره‌ای برای ساخت‌وساز عمومی است. به‌ویژه می‌خواهم این فراخوان را به کسانی خطاب کنم که هنوز عاشق ساختن هستند. «هکر» در اینجا به کسی اشاره دارد که مایل است بفهمد یک سیستم چگونه کار می‌کند، مایل است آنچه را کشف کرده به اشتراک بگذارد و مایل است بگذارد دیگران کار او را آزمایش کنند. آن روحیه زمانی اینترنت را به جلو راند و امروز می‌تواند کریپتو را نیز به جلو براند.

من باور ندارم این صنعت فاقد افراد باهوش است و باور ندارم صنایع کریپتو و هوش مصنوعی نمی‌توانند منابع لازم برای پشتیبانی از این کار را پیدا کنند. آنچه دشوارتر است، سازمان‌دهی هم‌زمان استعداد، بودجه و مسئولیت پایدار است. بنیادها و شرکت‌های توانمند باید مایل باشند هزینه بلندمدت کار بنیادینی را بپذیرند که مستقیماً درآمدزا نیست اما به همه سود می‌رساند.

امیدوارم همه بتوانند با هم برای ساختن زیرساخت رمزنگاری مشترک جهانی همکاری کنند. شبکه‌ها و تیم‌های مختلف می‌توانند تحت محدودیت‌های امنیتی مشترک همکاری کنند، هر یک راه‌حل‌های خود را پیاده‌سازی کنند و راه‌حل‌های یکدیگر را آزمایش کنند و کاربران بتوانند انتخاب و مهاجرت کنند. می‌توان آن را با یک مؤلفه واحد آغاز کرد، اما جهت باید به‌اندازه کافی بزرگ باشد تا کل صنعت را در ساختن مشترک جای دهد. همه مشارکت‌کنندگان، از جمله ArcBlock، باید کار قابل راستی‌آزمایی ارائه دهند.

باید مشترکاً نوعی زیرساخت بسازیم که حتی اگر بخشی از آن به خطر افتاده باشد، دارایی‌ها همچنان مرز داشته باشند، سیستم‌های دیگر همچنان بتوانند خطاها را رد کنند و کاربران همچنان مسیرهایی برای بازیابی و خروج داشته باشند. با وام گرفتن نام از جنگ ستارگان، این امید تازه ماست. [[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) امید از سازندگان معمولی می‌آید که مایل به اقدام هستند و همچنین از این لحظه که عامل‌های کدنویسی و روش‌های مهندسی جدید آن‌ها را قادر می‌سازد کار ساخت بیشتری را بر عهده بگیرند.من می‌خواهم از سازندگان پروژه‌هایی مانند Ethereum، Solana، Bitcoin و XRP Ledger، از صرافی‌هایی مانند Binance، Coinbase و Kraken، و همچنین از تیم‌های کیف پول، پروتکل، تحقیقات امنیتی، هوش مصنوعی و رایانش ابری دعوت کنم: با یک پایلوت با محدوده مشخص شروع کنید و به‌طور مشترک بهبودهایی تولید کنید که سایر تیم‌ها بتوانند آن‌ها را بپذیرند و آزمایش کنند.

نام‌های فهرست‌شده فقط نمونه هستند و به هیچ ترتیبی نیستند. صرف‌نظر از اندازه یا مسیر فنی که انتخاب می‌کنید، از مشارکت شما استقبال می‌شود. این دعوت همچنین شامل سازندگان مسیرهای فنی مورد انتقاد در این مقاله می‌شود؛ بهبود مشترک امنیت دارایی ارزش عبور از مرزهای اکوسیستم‌های respective ما را دارد.

من خودم مایلم مشارکت کنم و زیرساخت‌های موجود، مهندسی نرم‌افزار و شیوه‌های همکاری هوش مصنوعی خود را ارائه دهم. ما فقط یک تیم کوچک در این صنعت هستیم و آنچه می‌توانیم انجام دهیم محدود است. امیدوارم با یک نمونه اولیه و مجموعه‌ای از تست‌های قابل تکرار شروع کنیم.

افراد با تجربه عملیاتی می‌توانند سناریوهای حمله ناشناس‌سازی‌شده ارائه دهند، تیم‌های کیف پول و پروتکل می‌توانند محافظت‌ها را پیاده‌سازی کنند، و محققان مستقل می‌توانند تلاش کنند آن‌ها را دور بزنند. هر تیم بخشی را که می‌تواند انجام دهد بر عهده می‌گیرد، راه‌حل را به‌طور مشترک آزمایش می‌کند و در مورد گام بعدی تصمیم می‌گیرد.

من مایلم در سازماندهی الزامات محدودسازی و بازیابی دارایی در این مقاله به اولین مشخصات عمومی مشارکت کنم، و همچنین مایلم شیوه‌های فنی و مهندسی مرتبط را برای ساخت، همراه با سایر مشارکت‌کنندگان، یک AI Factory عمومی برای این پایلوت ارائه دهم. ابتدا یک مسئله بسیار مشخص را انتخاب کنید: زمانی که کلید تراکنش روزمره به خطر افتاده است، چگونه می‌توان همچنان از تخلیه یک‌باره کیف پول توسط مهاجم جلوگیری کرد؟ محدوده ضرر مجاز، اختیار تغییر قوانین و شرایط بازیابی را در تست‌های پذیرش بنویسید، سپس عامل‌های توسعه یک نمونه اولیه را پیاده‌سازی کنند، و گروه دیگری از عامل‌ها و محققان مستقل مسیرهای دور زدن را جستجو کنند. سرورهای داده که موجودی نادرست برمی‌گردانند، و بازیابی پس از از دست دادن دستگاه، نیز می‌توانند به تدریج به تست‌ها اضافه شوند. آنچه نمونه اولیه به دست می‌آورد، کجا شکست می‌خورد و چه وابستگی‌هایی باقی می‌ماند باید همه به‌طور عمومی توضیح داده شوند، و گام بعدی بر اساس شواهد تصمیم‌گیری شود.

کسانی که مایل به مشارکت هستند، خوشحال می‌شویم این ابتکار را به‌طور عمومی در X بازنشر یا نقل کنند و @mave99a را منشن کنند، و درباره مسئله‌ای که می‌خواهند حل کنند، موارد حمله ناشناس‌سازی‌شده، یا منابعی که می‌توانند ارائه دهند صحبت کنند. امیدوارم بحث به‌طور عمومی پیش برود تا سازندگان بیشتری آن را ببینند و بپیوندند.

کریپتو نمی‌تواند این‌گونه ادامه دهد. کسانی که مایل به همکاری هستند، بیایید همین حالا اقدام کنیم، با یک بهبود که می‌توان ساخت و می‌تواند در برابر تست مقاومت کند شروع کنیم.بایننس، پست رسمی اعلامیه اولیه و به‌روزرسانی رسمی تحقیقات بعدی، ۲۰۲۶-۱۰-۳۰؛ تحلیل چندزنجیره‌ای TRM. این پیش‌نویس تا تاریخ ۲۰۲۶-۱۰-۳۰ تأیید شده است؛ وضعیت تحقیق و بازیابی ممکن است تغییر کند. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)

ساتوشی ناکاموتو، بیت‌کوین: یک سیستم پول الکترونیکی همتا به همتا، ۲۰۰۸. [↩](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: تنظیم کد برای EOAها، ایجادشده در ۲۰۲۴-۰۵-۰۷. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)

مین‌فنگ چی، چین وانگ، روی‌چیانگ لی، تیان‌چینگ ژو، شیپینگ چن، حمله فیشینگ EIP-7702، ۲۰۲۵-۱۲-۱۳، پیش‌چاپ 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 ۲۰۲۶؛ به‌روزرسانی آسیب‌پذیری‌های شناخته‌شده و بهره‌برداری‌شده CISA ۲۰۲۶-۱۰-۲۶، CVE-2026-109618، CVE-2026-109619. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)

Safe، گاردها و ماژول‌ها، شرح عملکرد و ریسک‌های مجوز. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)

اپل، اپل گزینه‌های تعمیر را با پشتیبانی از قطعات اصلی مستعمل گسترش می‌دهد، ۲۰۲۴-۰۴-۱۱؛ شرح فعلی پشتیبانی جفت‌سازی قطعات. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)لجر، پاسخ لجر به حمله کاشت سخت‌افزاری، ۲۰۲۶-۱۰، بیانیه فروشنده درباره حمله در زنجیره توزیع؛ جو گرند، پژوهش مهندسی معکوس درباره کاشت‌های سخت‌افزاری. برآوردهای تأییدنشده از زیان شبکه را به‌عنوان نتیجه‌گیری قطعی ارائه نکنید. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)

کوین‌کایت، وضعیت فعلی امنیت COLDCARD، دسترسی‌یافته در ۲۰۲۶-۱۰-۳۰، سابقه پیوسته به‌روزرسانی‌شده حادثه ژوئیه ۲۰۲۶ و اصلاح آن؛ ارتقا و مهاجرت seed دو عملیات متمایز هستند. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)

ERC-4337: انتزاع حساب با استفاده از Alt Mempool؛ ترزور، پرسش‌های متداول SLIP39، بازیابی آستانه‌ای، سازگاری و ریسک‌های عبارت عبور اضافی. سازوکارهای موجود پایه‌ای برای ساخت هستند و به معنای قابل‌اعتماد بودن هر استقرار نیستند. [↩](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، مرور کلی اعتبارنامه‌های قابل تأیید نسخه ۱.۰، ۲۰۲۶-۰۷-۳۰ یادداشت گروهی؛ یادداشت‌های حریم خصوصی اتریوم. وضعیت استاندارد فناوری‌های توصیف‌شده در مرور کلی در هر مورد مستقل است. [↩](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 ترتیبات حضانت و صفحه ۴۵ افشای ریسک. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)

Mark Nottingham، RFC 9518: تمرکززدایی، عدم تمرکز و استانداردهای اینترنت، ۲۰۲۳-۱۲، ارسال‌شده به‌صورت مستقل، RFC اطلاعاتی، نه یک مشخصات مسیر استاندارد. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)

بخش ۸ وایت‌پیپر بیت‌کوین، تأیید پرداخت ساده‌شده؛ BIP-157: فیلتر بلوک سمت کلاینت؛ اتریوم، کلاینت‌های سبک. کلاینت‌های سبک مختلف دامنه تأیید و شرایط اعتماد متفاوتی دارند. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)

بنیاد اتریوم، اعلام ابتکار امنیت تریلیون دلاری، ۲۰۲۵-۰۵-۱۴. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)

Anthropic، هوش مصنوعی برای دفاع از زیرساخت حیاتی، ۲۰۲۶-۰۱-۰۸، پژوهش در محیط محدود با همکاری PNNL. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)

Anthropic، نقشه‌برداری تهدیدات سایبری مبتنی بر هوش مصنوعی، پژوهش بر نمونه‌های واقعی سوءاستفاده. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)

Lucasfilm، جنگ ستارگان: امیدی تازه (اپیزود چهارم)، ۱۹۷۷؛ این مقاله عنوان و تصویرسازی نجات جمعی را وام گرفته است. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)