تأیید پرداخت یک آستانه اطمینان است، نه تعداد ثابتی از بلاک‌ها
پرداخت بلاکچینی در یک لحظه یکسان برای همه شبکه‌ها کامل نمی‌شود. تراکنش ابتدا قابل مشاهده می‌شود؛ سپس ممکن است وارد بلاک شود، تأییدهای بیشتری بگیرد، به سطح قطعیت ویژه همان پروتکل برسد و در نهایت با سیاست پرداخت پذیرنده مطابقت پیدا کند.
هر مرحله پرسش متفاوتی را پاسخ می‌دهد. شناسایی یعنی سامانه تراکنش احتمالی را دیده است. تأیید یعنی شبکه تا چه اندازه موقعیت آن را پشتیبانی می‌کند. نهایی‌شدن یعنی معکوس‌کردن نتیجه چقدر دشوار یا استثنایی شده است. پذیرش تجاری می‌سنجد آیا این شواهد برای اقدام مشخصی مثل تحویل کالا یا اعتبار حساب کافی‌اند.
تمرکز این تحلیل بر مرز میان اطمینان شبکه و تصمیم کسب‌وکار است. مقاله «Blockchain Payments» مدل کامل تراکنش تا پرداخت را توضیح می‌دهد و تحلیل «Blockchain Consensus» مبنای اجماع و تاریخچه پذیرفته‌شده را بررسی می‌کند.
قابلیت مشاهده، ورود به بلاک، تأیید، نهایی‌شدن و پذیرش پنج مفهوم متفاوت‌اند
واژه «تأییدشده» در کیف پول، کاوشگر، نود، درگاه و داشبورد پذیرنده همیشه معنای یکسانی ندارد. سامانه قابل اعتماد باید معنای وضعیت‌های خودش را دقیق تعریف کند و صرفاً به برچسب رابط کاربری تکیه نکند.
- انتشار: کیف پول تراکنش امضاشده را ارسال کرده است؛ هنوز معلوم نیست شبکه آن را پذیرفته یا منتشر کرده باشد.
- شناسایی: یک یا چند مشاهده‌گر تراکنش را می‌بینند؛ تراکنش تأییدنشده هنوز ممکن است جایگزین، حذف یا معطل شود.
- ورود به بلاک: تراکنش در بلاک پیشنهادی یا پذیرفته‌شده ظاهر شده، اما تاریخچه تازه ممکن است تغییر کند.
- تأیید: شبکه برای موقعیت تراکنش شواهد بیشتری تولید کرده؛ این شواهد می‌توانند عمق بلاک، رأی اعتبارسنج یا سطح Commitment باشند.
- نهایی‌شدن: طبق فرض‌های امنیتی پروتکل، بازگرداندن تاریخچه به شکست استثنایی اجماع یا هزینه اقتصادی سنگین نیاز دارد.
- پذیرش: پذیرنده مبلغ، دارایی، شبکه، زمان، شناسه سفارش، ریسک و سیاست تحویل را بررسی کرده و اقدام بعدی را مجاز می‌داند.
بنابراین ممکن است مشتری درست بگوید «تراکنش در شبکه دیده می‌شود» و هم‌زمان فروشنده درست بگوید «پرداخت هنوز در انتظار است». آن‌ها دو لایه از یک واقعیت را گزارش می‌کنند؛ الزاماً تناقضی وجود ندارد.
منابع این بخش: OxaPay
تأیید عمدتاً از پرداخت در برابر تاریخچه ناپایدار و شاخه‌های رقیب محافظت می‌کند
نودهای یک شبکه ممکن است موقتاً بر سر تازه‌ترین تاریخچه معتبر اختلاف داشته باشند. اگر دو بلاک معتبر تقریباً هم‌زمان پیشنهاد شوند، قواعد انتخاب شاخه و نهایی‌شدن تعیین می‌کنند کدام تاریخچه معیار مشترک باشد.
بازآرایی زنجیره یا Reorg بخشی از تاریخچه اخیر را با شاخه دیگری جایگزین می‌کند. تراکنش ممکن است در بلاکی دیگر قرار بگیرد، دوباره به ممپول برگردد یا اگر خرج متعارضی پذیرفته شود، از زنجیره معیار حذف شود. عمق تأیید و سیگنال‌های قطعیت این ریسک را کاهش می‌دهند.
در بیت‌کوین، اثبات کار انباشته هزینه تغییر تاریخچه را افزایش می‌دهد. وایت‌پیپر بیت‌کوین نشان می‌دهد با پیش‌روی زنجیره صادق، احتمال رسیدن مهاجم کاهش می‌یابد؛ اما این تحلیل مجوز استفاده از یک عدد ثابت برای همه مبالغ نیست. محتوای ممپول هم محلی و موقت است و تراکنش‌های بلاک‌های کنارگذاشته‌شده می‌توانند دوباره به آن بازگردند.
منابع این بخش: Bitcoin Whitepaper · Bitcoin Developer Guide
شبکه‌های مختلف با سازوکارهای متفاوتی اطمینان و قطعیت ایجاد می‌کنند
«نهایی‌شدن» نام یک مکانیزم واحد نیست؛ قوی‌ترین ادعای برگشت‌ناپذیری هر شبکه با توجه به پروتکل و فرض‌های اعتماد آن است. درگاه پرداخت باید منبع این ادعا را بشناسد و بعد آن را به تصمیم پذیرنده تبدیل کند.
- قطعیت احتمالی: هرچه تاریخچه معتبر بیشتری روی بلاک ساخته شود، بازگردانی پرهزینه‌تر و کم‌احتمال‌تر می‌شود؛ لحظه قطعیت مطلق تعریف نشده است.
- قطعیت مبتنی بر رأی یا چک‌پوینت: اکثریت لازم اعتبارسنجان نقاطی از تاریخچه را نهایی می‌کنند؛ تغییر آن‌ها به نقض جدی فرض‌های شبکه یا زیان اقتصادی سنگین نیاز دارد.
- قطعیت چندلایه: پاسخ سریع یک لایه و تسویه مستحکم‌تر در لایه دیگر رخ می‌دهند؛ سکوئنسر، انتشار دسته تراکنش‌ها، اثبات و قطعیت زنجیره اصلی می‌توانند مراحل متفاوتی باشند.
اتریوم، انتخاب سر زنجیره را از قطعیت چک‌پوینت جدا می‌کند. در Gasper، رأی اکثریت دو‌سوم سهام برای توجیه و نهایی‌سازی چک‌پوینت‌ها اهمیت دارد؛ بنابراین «Head»، «Safe» و «Finalized» معادل هم نیستند. قطعیت اقتصادی قوی‌تر از صرف ورود به بلاک است، اما جایگزین ضمانت حقوقی یا امکان برگشت بانکی نمی‌شود.
منابع این بخش: Ethereum.org
سامانه چندزنجیره‌ای باید زبان‌های متفاوت اطمینان را به وضعیت‌های عملیاتی نگاشت کند
هر شبکه اصطلاحات و داده‌های مخصوص خود را برای میزان اطمینان دارد. سامانه پرداخت می‌تواند وضعیت‌های تجاری یکپارچه ارائه کند، اما نباید تضمین‌های امنیتی شبکه‌ها را یکسان فرض کند.
| شبکه | سیگنال اولیه | سیگنال قوی‌تر | تفسیر عملیاتی |
|---|---|---|---|
| بیت‌کوین | مشاهده در ممپول یا اولین بلاک | افزایش عمق تأیید | اطمینان احتمالی است و باید با ریسک مبلغ تناسب داشته باشد. |
| اتریوم | سر زنجیره یا ورود معمول به بلاک | چک‌پوینت‌های Safe و Finalized | قطعیت نهایی تضمین اقتصادی قوی‌تری از صرف ورود دارد. |
| سولانا | Processed | Confirmed و Finalized | Processed بازخورد سریع است اما در فورک امکان حذف دارد. |
| TON | وضعیت ردگیری پیام در انتظار یا تأیید | قطعیت مبتنی بر ارجاع مسترچین | پیام‌های غیرهم‌زمان و نتیجه نهایی زنجیره پیام باید بررسی شوند. |
مستندات سولانا سه سطح Processed، Confirmed و Finalized را تفکیک می‌کند. اسناد TON نیز بر ردگیری پیام‌ها و ارجاع مسترچین برای قطعیت تأکید دارند. برچسب مشترک پذیرنده مفید است، به شرط آنکه آداپتور زنجیره شواهد واقعی ایجادکننده آن را نگه دارد.
منابع این بخش: Solana Docs · TON Docs
آستانه درست تأیید به زیانی بستگی دارد که کسب‌وکار ممکن است متحمل شود
پذیرنده برای تمام پرداخت‌ها به بالاترین سطح قطعیت نیاز ندارد؛ فقط به اطمینان کافی برای اقدام موردنظر نیاز دارد. انتظار طولانی‌تر ممکن است ریسک شبکه را کاهش دهد، اما به تکمیل خرید، فعال‌سازی سرویس و اعتماد مشتری آسیب بزند.
- ارزش پرداخت: مبالغ بزرگ‌تر معمولاً به شواهد قوی‌تر و مدیریت محافظه‌کارانه‌تر استثناها نیاز دارند.
- قابلیت بازگرداندن تحویل: دسترسی قابل لغو با کالای دیجیتال غیرقابل بازپس‌گیری یا ارسال نهایی کالا ریسک یکسانی ندارد.
- شواهد شبکه: عمق تأیید، آرای اعتبارسنجان، وضعیت پیشرفت زنجیره و نشانه‌های Reorg باید مناسب همان شبکه باشند.
- فوریت عملیاتی: خرید خرده‌فروشی، دسترسی فوری، تسویه B2B و انتقال خزانه‌داری تحمل تأخیر متفاوتی دارند.
- استثناها: کسری مبلغ، شبکه اشتباه، انقضا یا پرداخت تکراری حتی با قطعیت بالا مستقل از مسئله نهایی‌شدن هستند.
«شش تأیید» یک قرارداد رایج برای اطمینان بیشتر در بیت‌کوین بوده، نه قاعده‌ای جهانی برای هر سفارش. اعتبار کم‌ارزش و قابل برگشت نباید الزاماً با تحویل B2B پرهزینه و برگشت‌ناپذیر یک سیاست داشته باشد.
منابع این بخش: OxaPay
شناسایی در ممپول تجربه کاربری را بهتر می‌کند، اما تسویه ایجاد نمی‌کند
نمایش «پرداخت شناسایی شد» قبل از ورود به بلاک به مشتری بازخورد فوری می‌دهد؛ خطر زمانی ایجاد می‌شود که همین سیگنال به‌اشتباه تحویل کالا را فعال کند.
ممپول یک اتاق انتظار جهانی نیست؛ هر نود مجموعه محلی و سیاست خودش را دارد. تراکنش با کارمزد ناکافی ممکن است دیر انتخاب شود یا از مجموعه برخی نودها حذف گردد؛ خرج متعارض یا جایگزینی نیز ممکن است وضعیت آن را تغییر دهد.
کارمزد رقابتی احتمال ورود سریع‌تر به بلاک را افزایش می‌دهد، اما ثابت نمی‌کند تراکنش با سفارش تطبیق دارد یا قطعیت کافی کسب کرده است. جزئیات رفتار ممپول و تأخیر شبکه در مقالات مرتبط OxaPay بررسی شده‌اند.
موتور تأیید، شواهد پروتکل را به یک تصمیم کنترل‌شده تبدیل می‌کند
سامانه عملیاتی نباید برچسب یک کاوشگر را بخواند و فوراً سفارش را کامل کند. باید شواهد را از منابع قابل اعتماد جمع‌آوری، تطبیق پرداخت را بررسی، سیاست پذیرنده را اعمال و دلیل هر تغییر وضعیت را ثبت کند.
- مشاهده: تراکنش‌ها، بلاک‌ها، سیگنال‌های Commitment و سلامت شبکه را با منبع و زمان ثبت کنید.
- تفسیر شبکه: سیگنال‌های بومی مانند Processed، Included، Safe، Finalized و عمق بلاک را بدون حذف تفاوت‌هایشان به داده اطمینان تبدیل کنید.
- اعتبارسنجی پرداخت: دارایی، شبکه، مبلغ، مقصد، سفارش و زمان را مطابقت دهید؛ یک تراکنش نهایی ممکن است هنوز پرداخت اشتباه باشد.
- ارزیابی سیاست: براساس سطح مبلغ، قابلیت بازگرداندن عمل، سلامت شبکه و استثناها، آستانه اطمینان را تعیین کنید.
- تغییر کنترل‌شده: یک گذار وضعیت با سابقه ممیزی و قابلیت پردازش بدون اثر تکراری صادر کنید تا Polling و Webhook تکراری دو بار تحویل ایجاد نکنند.
پایش چندمنبعی و بازیابی رویدادهای جامانده در Deep Insight مربوط به Real-Time Monitoring بررسی می‌شود؛ ماشین وضعیت پرداخت نیز طراحی اختصاصی خودش را می‌خواهد. موضوع این مقاله دقیقاً تصمیم اطمینان میان این دو لایه است.
منابع این بخش: OxaPay
پرداخت لایه دوم می‌تواند تأیید محلی سریع و قطعیت زنجیره اصلی دیرتر داشته باشد
تراکنش Rollup ممکن است فوری از سکوئنسر پاسخ بگیرد، بعد در یک دسته منتشر شود و در نهایت از زنجیره اصلی اطمینان تسویه بگیرد. این نقاط هم‌زمان نیستند و هرکدام فرض اعتماد متفاوتی دارند.
Optimism وضعیت‌های Unsafe، Safe و Finalized را تعریف می‌کند: تراکنش Unsafe اجرا شده اما هنوز در لایه اول ثبت نشده؛ Safe روی لایه اول نوشته شده ولی ممکن است تحت تأثیر Reorg آن قرار بگیرد؛ Finalized به تاریخچه نهایی‌شده لایه اول متکی است.
در Arbitrum نیز بازخورد سریع سکوئنسر نوعی قطعیت نرم است که با انتشار و نهایی‌شدن داده‌ها روی زنجیره اصلی قوی‌تر می‌شود. بنابراین رسید سریع برای نمایش وضعیت مناسب است، اما تسویه باارزش ممکن است به انتشار دسته، قطعیت لایه اول، تکمیل اثبات یا پیام میان‌زنجیره‌ای نیاز داشته باشد.
منابع این بخش: Optimism Docs · Arbitrum Docs
یک وضعیت تراکنش می‌تواند در کسب‌وکارهای مختلف به اقدامات متفاوت منجر شود
- اعتبار حساب کم‌ارزش: شناسایی را فوری نمایش دهید، پس از آستانه مشخص اعتبار موقت بدهید و برداشت را تا قطعیت قوی‌تر محدود کنید.
- تحویل محصول دیجیتال: اگر دانلود یا مجوز قابل پس‌گرفتن نیست، پیش از تحویل به اطمینان بیشتری نیاز دارید.
- فاکتور B2B با مبلغ بالا: نهایی‌شدن شبکه را با تطبیق دقیق فاکتور، بررسی شواهد و کنترل خزانه‌داری ترکیب کنید.
- کالای فیزیکی: مشاهده تراکنش می‌تواند فرایند بسته‌بندی را شروع کند، ولی ارسال نهایی تا آستانه اطمینان لازم صبر کند.
- فاکتور منقضی یا کم‌پرداخت‌شده: حتی تراکنش کاملاً نهایی‌شده ممکن است به تکمیل مبلغ، بازپرداخت، قیمت‌گذاری جدید یا بررسی دستی نیاز داشته باشد.
ارتباط روشن و سریع درباره وضعیت، فشار پشتیبانی و احساس تأخیر را کاهش می‌دهد؛ اما پیام «شناسایی شد» نباید به‌صورت تکمیل برگشت‌ناپذیر عرضه شود.
منابع این بخش: OxaPay
OxaPay وضعیت پرداخت را برای اتصال پیشرفت شبکه به عملیات پذیرنده ارائه می‌کند
ساخت جداگانه آداپتور شبکه‌ها، قواعد تأیید، تطبیق پرداخت، اعلان‌ها و پردازش مجدد برای کسب‌وکار پیچیده است. OxaPay امکان ساخت درخواست پرداخت ساختاریافته و دریافت تغییر وضعیت را از طریق رابط‌های پرداخت فراهم می‌کند.
Generate Invoice API می‌تواند مبلغ، ارز، مدت اعتبار، شناسه سفارش، پوشش کسری مبلغ، گزینه‌های پرداخت ترکیبی و URL وبهوک را حمل کند. این فیلدها زمینه تجاری لازم را تعیین می‌کنند؛ زمینه‌ای که خود تأیید بلاکچین به‌تنهایی فراهم نمی‌سازد.
مستندات Webhook میان به‌روزرسانی اولیه Paying و وضعیت بعدی Paid تفاوت می‌گذارد و اعتبارسنجی HMAC و تلاش مجدد ارسال را توضیح می‌دهد. سامانه پذیرنده باید پیام‌ها را امن و بدون اثر تکراری پردازش کند، بعد پاسخ موفق مناسب بدهد و هر گذار را ثبت کند.
- تعریف پرداخت: فاکتور را با مبلغ، زمان، شناسه سفارش و قواعد استثنا ایجاد کنید.
- دریافت تغییر وضعیت: به‌جای تکیه بر Redirect مشتری، اعلان سروربه‌سرور معتبر را بررسی کنید.
- اقدام پذیرنده: وضعیت Paid را به تحویل، فعال‌سازی، حسابداری یا بررسی دستی طبق سیاست خودتان نگاشت کنید.
منابع این بخش: OxaPay Docs · OxaPay Docs · OxaPay Docs · OxaPay
پیش از اقدام برگشت‌ناپذیر، پنج پرسش کنترلی را بررسی کنید
- هویت پرداخت: دارایی، شبکه، نشانی، مبلغ و سفارش درست هستند؟ قطعیت بالا، پرداخت اشتباه را درست نمی‌کند.
- شواهد بومی شبکه: تراکنش دقیقاً به چه سطحی از تأیید یا قطعیت رسیده و مستند آن چیست؟
- سلامت شبکه: آیا زنجیره به‌طور عادی پیش می‌رود یا تأخیر قطعیت، Reorg، توقف سکوئنسر و اختلاف ارائه‌دهندگان دیده می‌شود؟
- زیان تجاری: اگر وضعیت بعداً تغییر کند، زیان احتمالی و دشواری بازیابی چقدر است؟
- گذار کنترل‌شده: آیا سامانه می‌تواند اقدام را دقیقاً یک بار انجام دهد و با لاگ، تطبیق و قواعد Override علتش را توضیح دهد؟
سیاست بهتر لزوماً کندترین سیاست نیست. باید کمترین سطح اطمینانی را انتخاب کند که اقدام موردنظر را به‌طور ایمن پشتیبانی کند و همان وضعیت را شفاف به مشتری توضیح دهد.
برای ادعاهای قطعیت به منابع پروتکل و برای پیاده‌سازی به مستندات OxaPay رجوع کنید
اصطلاحات و سازوکارهای قطعیت ممکن است با ارتقای شبکه تغییر کنند. سیاست پرداخت باید بر اسناد فنی اولیه هر زنجیره بنا شود، نه صرفاً مقایسه‌های عمومی.
- بیت‌کوین: وایت‌پیپر و راهنمای شبکه همتابه‌همتا برای امنیت احتمالی، شاخه‌های رقیب، ممپول و بلاک‌های کنارگذاشته‌شده.
- اتریوم: مستندات اثبات سهام و Gasper برای انتخاب شاخه، توجیه و نهایی‌سازی چک‌پوینت‌ها.
- سولانا: راهنمای تأیید پرداخت و RPC برای Processed، Confirmed و Finalized.
- TON: راهنمای پردازش پرداخت برای پیام‌های غیرهم‌زمان و ارجاع مسترچین.
- لایه دوم: اسناد Optimism و Arbitrum برای پاسخ اولیه سکوئنسر، قطعیت نرم و قطعیت زنجیره اصلی.
برای پیاده‌سازی در OxaPay، مستندات Invoice API، Webhook و سرویس Crypto Invoice مسیر ارتباط وضعیت شبکه با عملیات پذیرنده را توضیح می‌دهند.
منابع این بخش: Bitcoin Whitepaper · Bitcoin Developer Guide · Ethereum.org · Ethereum.org · Solana Docs · Solana Docs · TON Docs · Optimism Docs · Arbitrum Docs · OxaPay Docs · OxaPay Docs · OxaPay