کیف پول صرافی ارز دیجیتال چگونه کار می‌کند؟

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

بسیاری از کاربران تصور می‌کنند صرافی برای هر مشتری یک کیف پول مستقل می‌سازد و تمام خریدوفروش‌های او را نیز روی بلاکچین ثبت می‌کند. در صورتی که یک صرافی متمرکز ممکن است برای کاربران آدرس‌های واریز جداگانه ایجاد کند، اما دارایی‌ها را بعداً در چند کیف پول اصلی تجمیع کند. در این مدل، سهم هر کاربر در Internal Ledger (دفترکل داخلی) صرافی ثبت می‌شود.

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

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

کیف پول صرافی چیست؟

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

در بیشتر صرافی‌های متمرکز، کاربر از یک Custodial Wallet (کیف پول امانی) استفاده می‌کند. در این مدل، صرافی یا شرکت متولی طرف قرارداد آن، Private Key (کلید خصوصی) لازم برای امضای تراکنش‌ها را مدیریت می‌کند. کاربر با نام کاربری، رمز عبور و روش‌های احراز هویت وارد حساب خود می‌شود، اما معمولاً کلید خصوصی کیف پول‌های اصلی را در اختیار ندارد. توافق‌نامه فعلی Coinbase نیز توضیح می‌دهد که کلیدهای خصوصی کیف پول میزبانی‌شده را این شرکت نگهداری می‌کند و ممکن است بخشی از دارایی‌ها را در آدرس‌های مشترک تحت کنترل خود قرار دهد.

منبع: توافق‌نامه کاربران Coinbase

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

منبع: راهنمای کیف پول  Ethereum

کیف پول صرافی چگونه کار می‌کند؟

فرض کنید ندا ۱۰۰۰ تتر به صرافی واریز می‌کند، با ۳۰۰ تتر بیت‌کوین می‌خرد و سپس بخشی از دارایی خود را برداشت می‌کند.

۱. صرافی مقصد واریز را مشخص می‌کند.

صرافی بر اساس ارز و شبکه انتخاب‌شده، یک آدرس واریز به ندا نشان می‌دهد. این آدرس ممکن است فقط به او اختصاص داشته باشد یا همراه با Memo (یادداشت تراکنش) یا Destination Tag (تگ مقصد) به یک حساب مشترک متصل شود. سیستم مدیریت آدرس باید بداند هر آدرس یا شناسه به کدام کاربر تعلق دارد.

۲. سیستم تراکنش را روی شبکه شناسایی می‌کند.

پس از ارسال تتر، سرویس متصل به بلاکچین تراکنش را مشاهده می‌کند. مشاهده اولیه برای شارژ حساب کافی نیست و صرافی معمولاً منتظر تعداد مشخصی از Confirmations (تأییدهای شبکه) یا رسیدن تراکنش به سطح موردنظر از Finality  (نهایی‌شدن) می‌ماند.

۳. دفترکل داخلی موجودی کاربر را افزایش می‌دهد.

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

۴. صرافی ممکن است دارایی را به خزانه منتقل کند.

صرافی می‌تواند تتر دریافت‌شده را با فرایند Sweep (انتقال تجمیعی) از آدرس واریز به یک کیف پول عملیاتی یا خزانه مرکزی منتقل کند. این جابه‌جایی به معنی برداشت کاربر نیست و نباید موجودی ثبت‌شده او را کاهش دهد. مستندات Fireblocks نیز الگوی Omnibus (تجمیعی) را توضیح می‌دهد که در آن، دارایی کاربران از کیف پول‌های اختصاصی به یک کیف پول خزانه منتقل می‌شود.

منبع: مدیریت واریز در مقیاس بالا در Fireblocks

۵. معامله در حساب‌های داخلی ثبت می‌شود.

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

۶. برداشت، دارایی را دوباره وارد مسیر بلاکچین می‌کند.

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

انواع کیف پول در صرافی ارز دیجیتال

۱. کیف پول گرم و سرد صرافی

• Hot Wallet (کیف پول گرم): به زیرساختی گفته می‌شود که برای عملیات آنلاین و برداشت‌های روزمره در دسترس قرار دارد. صرافی می‌تواند درخواست‌های مجاز را با سرعت بیشتری از این کیف پول پردازش کند. دسترس‌پذیری بالا، سطح حمله و هک را نیز افزایش می‌دهد و به همین دلیل، موجودی کیف پول گرم باید محدود و به‌طور مداوم رصد شود.
• Cold Wallet (کیف پول سرد): کلید یا فرایند امضا را از محیط آنلاین جدا نگه می‌دارد. دریافت دارایی به آدرس سرد به اتصال دستگاه امضاکننده نیاز ندارد، اما برداشت از آن معمولاً مراحل بیشتری را طی می‌کند. راهنمای توسعه‌دهندگان Bitcoin توضیح می‌دهد که در یک الگوی آفلاین، تراکنش در محیط متصل ساخته می‌شود، در محیط جداگانه بررسی و امضا می‌شود و سپس برای انتشار به محیط آنلاین بازمی‌گردد.

منبع: راهنمای کیف پول‌های آفلاین Bitcoin

برخی مجموعه‌ها از اصطلاح Warm Wallet (کیف پول نیمه‌گرم) نیز استفاده می‌کنند. این اصطلاح استاندارد واحدی ندارد، اما معمولاً به لایه‌ای اشاره می‌کند که از کیف پول گرم محدودتر و از ذخیره سرد در دسترس‌تر است. چنین لایه‌ای می‌تواند میان برداشت‌های روزمره و ذخایر اصلی تعادل ایجاد کند.

معیار	Hot Wallet (کیف پول گرم)	Warm Wallet (کیف پول نیمه گرم)	Cold Wallet (کیف پول سرد)
کاربرد اصلی	برداشت‌های روزمره و سریع	تأمین دوره‌ای کیف پول گرم و انتقال‌های کنترل‌شده	نگهداری بخش اصلی ذخایر
وضعیت دسترسی	آنلاین و خودکارتر	محدود، زمان‌بندی‌شده یا نیازمند تأیید بیشتر	آفلاین یا کاملاً جدا از محیط عملیاتی
سرعت عملیات	بالاتر	متوسط	پایین‌تر
ریسک مهم	نفوذ به سرویس آنلاین یا سوءاستفاده از دسترسی	خطای سیاست‌گذاری یا تأیید نامناسب	ضعف در پشتیبان، بازیابی یا فرایند امضای آفلاین

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

۲. کیف پول واریز، برداشت و خزانه

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

۳. کیف پول تجمیعی و تفکیک‌شده

• Omnibus Wallet (کیف پول تجمیعی): دارایی چند کاربر در یک یا چند کیف پول مشترک نگهداری می‌شود و سهم هر کاربر در دفترکل داخلی باقی می‌ماند.
• Segregated Wallet (کیف پول تفکیک‌شده): دارایی مشتریان یا گروه‌های مختلف در کیف پول‌های جدا قرار می‌گیرد. مدل دوم شفافیت عملیاتی بیشتری ایجاد می‌کند، اما تعداد آدرس‌ها، تراکنش‌های تجمیعی و هزینه مدیریت را نیز افزایش می‌دهد.

امانی یا خودامانی بودن با گرم یا سرد بودن، یک دسته‌بندی واحد نیست. امانی بودن نشان می‌دهد چه کسی اختیار امضا را کنترل می‌کند، درحالی‌که گرم یا سرد بودن به شیوه دسترسی به محیط امضا مربوط می‌شود. یک صرافی می‌تواند هم کیف پول گرم امانی و هم کیف پول سرد امانی داشته باشد.

فرآیند واریز ارز به صرافی

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

۱. انتخاب ارز و شبکه درست

کاربر ابتدا دارایی و شبکه را انتخاب می‌کند. نام USDT (تتر) به‌تنهایی مسیر انتقال را مشخص نمی‌کند، زیرا تتر روی چند شبکه عرضه شده است. اگر صرافی برای واریز، شبکه TRON را نمایش دهد، ارسال تتر از مسیر Ethereum به همان صفحه می‌تواند باعث شارژ نشدن خودکار حساب شود. کاربر باید شبکه مبدأ و مقصد، حداقل مبلغ و هشدارهای صفحه واریز را پیش از ارسال بررسی کند.

۲. دریافت آدرس و شناسه تکمیلی

صرافی یک آدرس واریز نمایش می‌دهد. برخی شبکه‌ها علاوه بر آدرس، به شناسه‌ای مانند Memo یا Destination Tag نیاز دارند. برای نمونه، در XRP Ledger، تگ مقصد می‌تواند مشخص کند که یک پرداخت واردشده به آدرس مشترک صرافی باید به حساب کدام مشتری اختصاص یابد.

منبع: مستندات Source and Destination Tags در XRP Ledger

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

۳. شناسایی تراکنش و انتظار برای تأیید

سرویس ارتباط با بلاکچین، تراکنش ورودی را شناسایی می‌کند و وضعیت آن را زیر نظر می‌گیرد. تعداد تأییدهای لازم برای تمام ارزها و صرافی‌ها یکسان نیست. برای نمونه، Kraken در راهنمای فعلی خود اعلام می‌کند که واریز Bitcoin را پس از چهار تأیید به حساب مشتری منظور می‌کند و این فرایند در شرایط معمول حدود ۴۰ دقیقه طول می‌کشد. این زمان تضمین‌شده نیست و با وضعیت شبکه تغییر می‌کند.

منبع: زمان پردازش واریز در Kraken

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

۴. ثبت موجودی و انتقال احتمالی به خزانه

پس از تأیید، دفترکل داخلی مبلغ را به حساب کاربر اضافه می‌کند. سیستم ممکن است بعداً دارایی را از آدرس واریز به کیف پول خزانه انتقال دهد. به همین دلیل، کاهش موجودی یک آدرس واریز در Block Explorer (مرورگر بلاکچین) لزوماً به معنی کاهش موجودی حساب کاربر نیست.

سیستم باید از ثبت دوباره یک واریز جلوگیری کند. اعلان‌های شبکه یا Webhook (وب‌هوک) ممکن است تکراری یا خارج از ترتیب به صرافی برسند. مستندات Fireblocks نیز توصیه می‌کند شناسه رویدادها ثبت شود، رویدادهای تکراری نادیده گرفته شوند و پردازش به ترتیب رسیدن اعلان‌ها وابسته نباشد.

منبع: راهنمای Webhook در Fireblocks

اگر واریز در حساب نمایش داده نشد، کاربر باید ابتدا Transaction ID یا TxID (شناسه تراکنش)، شبکه انتخاب‌شده، تعداد تأییدها و تگ مقصد را بررسی کند. پشتیبانی برای پیگیری واریز به عبارت بازیابی یا کلید خصوصی کاربر نیاز ندارد و کاربر نباید این اطلاعات را در اختیار هیچ فردی قرار دهد.

۵. فرآیند برداشت ارز از صرافی

درخواست برداشت کاربر پس از فشردن دکمه تایید، باید از چند کنترل مالی و امنیتی عبور کند و سپس به یک تراکنش معتبر روی شبکه تبدیل شود.

۶. ثبت درخواست و رزرو موجودی

کاربر دارایی، شبکه، آدرس مقصد و مبلغ را وارد می‌کند. سیستم باید موجودی قابل‌برداشت، کارمزد، سقف‌ها و محدودیت‌های حساب را کنترل کند. سپس مبلغ لازم را Reserve (رزرو) می‌کند تا کاربر نتواند همان دارایی را هم‌زمان در سفارش دیگری مصرف یا دوباره برداشت کند.

۷. کنترل ریسک و تأیید هویت

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

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

منبع: راهنمای Transaction Authorization در OWASP

۸. ساخت و امضای تراکنش

پس از تأیید درخواست، Wallet Service (سرویس کیف پول) داده‌های تراکنش را می‌سازد، Policy Engine (موتور سیاست‌گذاری) باید مجاز بودن عملیات را بررسی کند و Signer (سرویس امضا) فقط درخواست‌هایی را امضا کند که تمام شرایط لازم را دارند. این جداسازی از آن جلوگیری می‌کند که نفوذ به یک بخش از سامانه، به‌تنهایی اختیار انتقال دارایی را ایجاد کند.

۹. ارسال به شبکه و پیگیری نتیجه

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

اگر پاسخ نود یا ارائه‌دهنده زیرساخت به صرافی نرسد، سیستم نباید بلافاصله تراکنش دیگری بسازد. ممکن است تراکنش نخست به شبکه ارسال شده باشد، اما پاسخ آن از بین رفته باشد. سامانه باید نتیجه قبلی را با شناسه‌ها، Nonce (شماره ترتیبی تراکنش) یا داده‌های شبکه بررسی کند تا پرداخت تکراری رخ ندهد.

۱۰. نهایی‌سازی حساب و تطبیق مالی

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

تفاوت کیف پول صرافی و کیف پول شخصی

مهم‌ترین تفاوت والت صرافی و والت شخصی به کنترل کلید و مسئولیت نگهداری مربوط می‌شود. در این مقایسه، منظور از والت شخصی یک Self-custody Wallet (کیف پول خودامانی) است.

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

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

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

امنیت کیف پول صرافی چگونه تأمین می‌شود؟

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

۱. حفاظت از کلیدها و محیط امضا

کلید خصوصی نباید به‌صورت متن ساده در پایگاه داده، فایل تنظیمات، کد برنامه یا گزارش‌های سیستم ذخیره شود. HSM یا Hardware Security Module (ماژول امنیتی سخت‌افزاری) می‌تواند عملیات رمزنگاری و امضا را در یک محیط محافظت‌شده انجام دهد. OWASP نیزتوصیه می‌کند کلیدها در خزانه رمزنگاری مانند HSM یا یک سرویس رمزنگاری ایزوله نگهداری شوند و کد عادی برنامه به کلید خام دسترسی نداشته باشد.

منبع: راهنمای Key Management در OWASP

برخی زیرساخت‌ها از MPC یا Multi-Party Computation (محاسبات چندطرفه) استفاده می‌کنند و برخی دیگر از Multi-signature (امضای چندگانه) بهره می‌برند. این فناوری‌ها سازوکار یکسانی ندارند، اما هر دو می‌توانند اختیار امضا را از یک نقطه منفرد دور کنند. امنیت واقعی زمانی شکل می‌گیرد که روش انتخاب‌شده با سیاست دسترسی، بازیابی، ثبت رویداد و تأیید تراکنش هماهنگ باشد.

۲. احراز هویت و حفاظت از حساب کاربر

MFA یا Multi-Factor Authentication (احراز هویت چندعاملی) احتمال سوءاستفاده از یک رمز عبور سرقت‌شده را کاهش می‌دهد. صرافی باید تغییر رمز، تعویض عامل دوم، بازیابی حساب، افزودن آدرس برداشت و غیرفعال‌سازی کنترل‌های امنیتی را به‌عنوان عملیات حساس در نظر بگیرد. OWASP نیز هشدار می‌دهد که مسیر بازیابی یا تعویض عامل دوم نباید به راه ساده‌تری برای دور زدن MFA تبدیل شود.

منبع: راهنمای MFA در OWASP

۳. کنترل دسترسی و تفکیک وظایف

کارمند پشتیبانی، مدیر مالی و مسئول زیرساخت نباید دسترسی یکسانی داشته باشند Role-Based Access Control یا RBAC (کنترل دسترسی مبتنی بر نقش)، اصل Least Privilege (حداقل سطح دسترسی) و تأیید چندنفره برای عملیات حساس، احتمال خطا یا سوءاستفاده یک حساب را کاهش می‌دهند. تغییر سیاست برداشت یا فهرست آدرس‌های مجاز نیز باید ثبت و کنترل شود.

۴. موتور ریسک و سیاست برداشت

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

۵. پایش، هشدار و تطبیق موجودی

سیستم باید کاهش غیرعادی موجودی کیف پول گرم، افزایش برداشت ناموفق، تراکنش‌های معطل و اختلاف میان موجودی شبکه و دفترکل را شناسایی کند. Reconciliation (تطبیق حساب‌ها) باید به‌صورت منظم یا نزدیک به زمان واقعی انجام شود. Fireblocks نیز پیش از شارژ حساب مشتری، تطبیق وضعیت تراکنش و موجودی را با وضعیت بلاکچین توصیه می‌کند.

منبع: راهنمای Validate Balances در Fireblocks

۶. پشتیبان‌گیری و برنامه بازیابی

نسخه پشتیبان فقط زمانی ارزش دارد که صرافی بتواند آن را در یک سناریوی واقعی بازیابی کند. برنامه Disaster Recovery (بازیابی پس از بحران) باید خرابی دستگاه امضا، از دست رفتن دسترسی، اختلال نود، توقف سرویس ثالث و خطای انسانی را پوشش دهد. نسخه‌های پشتیبان نیز باید رمزنگاری، تفکیک و کنترل شوند تا خودشان به مسیر نفوذ تبدیل نشوند. FBI اعلام کرد که در فوریه ۲۰۲۵ حدود ۱٫۵ میلیارد دلار دارایی مجازی در حمله به Bybit (از بزرگترین هک‌های ارز دیجیتال) سرقت شد. این حادثه نشان داد که ارزش دارایی تحت مدیریت صرافی می‌تواند هر نقص در زنجیره تأیید و انتقال را به یک ریسک بسیار بزرگ تبدیل کند

منبع: اطلاعیه رسمی FBI و IC3 درباره حمله Bybit

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

معماری کیف پول در یک صرافی چگونه است؟

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

بخش معماری	مسئولیت اصلی	پیامد طراحی ضعیف
Blockchain Gateway	این بخش با Node یا ارائه‌دهنده شبکه ارتباط برقرار می‌کند و تراکنش‌ها و وضعیت آن‌ها را می‌خواند.	تراکنش‌های ورودی دیر شناسایی می‌شوند یا وضعیت نادرست به سیستم می‌رسد.
Address Management	این بخش آدرس، Memo یا Tag را به کاربر و شبکه درست مرتبط می‌کند.	واریز به حساب اشتباه اختصاص می‌یابد یا نیازمند بررسی دستی می‌شود.
Internal Ledger	این بخش موجودی آزاد، رزروشده و قطعی هر کاربر را ثبت می‌کند.	موجودی کاربران با معاملات، برداشت‌ها یا ذخایر واقعی ناسازگار می‌شود.
Wallet Orchestrator	این بخش جریان واریز، Sweep، تأمین کیف پول گرم و برداشت را هماهنگ می‌کند.	عملیات تکراری، ناقص یا خارج از ترتیب اجرا می‌شوند.
Risk and Policy Engine	این بخش قواعد مبلغ، مقصد، دسترسی و تأیید را اعمال می‌کند.	درخواست پرریسک بدون کنترل کافی به مرحله امضا می‌رسد.
Signing Service	این بخش تراکنش مجاز را با  HSM ،MPC یا روش مصوب امضا می‌کند.	کلید یا اختیار امضا به یک نقطه آسیب‌پذیر تبدیل می‌شود.
Treasury Management	این بخش نقدینگی را میان کیف پول گرم، نیمه‌گرم و سرد جابه‌جا می‌کند.	کیف پول گرم خالی می‌شود یا دارایی بیش از نیاز در محیط آنلاین باقی می‌ماند.
Monitoring and Reconciliation	این بخش رویدادها، موجودی‌ها و اختلاف میان دفترکل و شبکه را کنترل می‌کند.	خطا یا نفوذ دیر شناسایی می‌شود و اختلاف مالی گسترش پیدا می‌کند.

دفترکل داخلی در این معماری نقش محوری دارد. یک صرافی نباید موجودی کاربر را فقط با تغییر یک عدد در جدول به‌روزرسانی کند. Double-entry Bookkeeping (حسابداری دوطرفه) باعث می‌شود هر انتقال، مبدأ و مقصد مشخصی داشته باشد و هر تغییر با ثبت متناظر همراه شود.

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

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

جمع‌بندی

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

 

سؤالات متداول

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

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

۳. آیا هر کاربر صرافی کیف پول جداگانه دارد؟
خیر. ممکن است هر کاربر آدرس واریز جداگانه داشته باشد، اما صرافی دارایی‌ها را بعداً در کیف پول‌های تجمیعی نگهداری کند. در برخی شبکه‌ها نیز همه کاربران از یک آدرس مشترک همراه با Memo یا Tag اختصاصی استفاده می‌کنند. دفترکل داخلی سهم هر کاربر را از موجودی‌های مشترک جدا می‌کند.

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

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