شناسایی تراکنش، تأیید زنجیره، ارتباط سفارش و تحویل سرویس مراحل جداگانه‌ای هستند. زنجیره، دارایی، گیرنده و مبلغ صحیح را بررسی کنید؛ یک سیاست پذیرش مستند اعمال کنید؛ و تطبیق را خودتوان کنید. یک مرجع تراکنش، تصویر صفحه یا دکمه مرورگر به‌تنهایی نمی‌تواند ثابت کند که یک سفارش خاص پرداخت شده است.
رویداد زنجیره را از رویداد سفارش جدا کنید
گزارش یک کیف پول مبنی بر ارسال انتقال، شاهدی بر عمل خود آن است، نه یک تصمیم کامل پرداخت. بک‌اند دریافت‌کننده باید شبکه موردنظر را مشاهده کند، انتقال واقعی را بررسی کند و آن را به یک سفارش مرتبط کند. تنها در این صورت است که سفارش می‌تواند سیاست پذیرش خود را اعمال کند. تحویل زیرساخت یک گام عملیاتی دیگر پس از پذیرش پرداخت است.
این گذارها را هم در کد و هم در زبان مشتری صریح نگه دارید. یک صفحه می‌تواند در انتظار، شناسایی‌شده یا در حال تأیید را نشان دهد بدون اینکه سفارش را پرداخت‌شده بنامد. اجازه ندهید مرورگر مبلغ پذیرفته‌شده را تأمین کند یا یک وضعیت معتبر را بازنویسی کند. نقل‌قول ایجادشده توسط سرور و دستورالعمل‌های آن را ذخیره کنید تا تطبیق بعدی بتواند در برابر سفارش اصلی ارزیابی شود، نه یک سبد خرید متغیر.
از قواعد اطمینان مخصوص هر زنجیره استفاده کنید
شبکه‌های مختلف اطمینان تراکنش را به شکل متفاوتی توصیف می‌کنند. راهنمای توسعه‌دهنده Bitcoin توضیح می‌دهد که گره‌ها چگونه زنجیره‌ای با بیشترین اثبات کار انباشته را انتخاب می‌کنند و چگونه بلوک‌های رقیب می‌توانند رخ دهند. بنابراین یک تراکنش که اخیراً دیده شده است به سیاستی برای عمق تأیید و تغییرات احتمالی زنجیره نیاز دارد. هیچ تعداد تأیید واحدی برای هر دارایی و ریسک تجاری مناسب نیست.
مستندات اثبات سهام Ethereum نهایی‌بودن نقطه بازرسی را توضیح می‌دهد، در حالی که Solana وضعیت‌های تعهد پردازش‌شده، تأییدشده و نهایی‌شده را مستند می‌کند. این اصطلاحات را به‌سادگی به یک تعداد بلوک جهانی ترجمه نکنید. قاعده مخصوص شبکه، منبع اطلاعات و رفتار در زمان ابهام را ثبت کنید. اپراتور باید آستانه‌های پذیرش را در برابر ریسک پرداخت و تحویل تعیین کند، نه اینکه عددی را از یک تسویه نامرتبط کپی کند.
محتوای واقعی انتقال را بررسی کنید
گیرنده، دارایی و مبلغ را روی زنجیره صحیح شناسایی کنید. پرداخت‌های توکنی به هویت توکن موردنظر نیاز دارند، نه صرفاً یک تراکنش موفق به یک آدرس. موفقیت اجرای مربوطه و شواهد انتقال را بر اساس مدل زنجیره بررسی کنید. مبالغ صحیح را با دقت مناسب دارایی تجزیه کنید، نه اینکه به یک اعشار قالب‌بندی‌شده ارائه‌شده توسط مرورگر اعتماد کنید.
یک دستورالعمل پرداخت باید به مسیر اصلی خود متصل بماند. یک انتقال روی شبکه دیگر، یک توکن متفاوت با نماد یکسان یا یک مرجع تراکنش نامرتبط نباید آن را برآورده کند. سابقه تأیید باید توضیح دهد چه چیزی بررسی شده است و شواهد لازم برای بازبینی تصمیم را حفظ کند. این راهنما اصول کلی تطبیق پرداخت را توصیف می‌کند، نه پیاده‌سازی یک سرویس خاص را.
ارتباط سفارش را بدون ابهام کنید
آدرس‌های دریافت ثابت می‌توانند چندین سفارش با مبالغ مشابه دریافت کنند. وجود یک انتقال منطبق ثابت نمی‌کند که کدام مشتری یا سفارش باید اعتبار بگیرد. روش ارتباط را پیش از پذیرش پرداخت‌های زنده تعریف کنید و مدیریت برخوردها را نیز بگنجانید. یک مرجع تراکنش ارائه‌شده توسط کاربر همچنان نیازمند اعتبارسنجی است که همان انتقال قبلاً جای دیگری تخصیص داده نشده باشد.
تصور کنید دو فاکتور برای مبلغ یکسان روی مسیر یکسان در یک بازه همپوشان وجود دارد. یک ناظر یک انتقال می‌بیند. علامت‌گذاری خودکار هر دو به‌عنوان پرداخت‌شده نادرست است؛ انتخاب یکی بدون شواهد کافی نیز ناایمن است. انتقال را تخصیص‌نیافته یا در بازبینی نگه دارید تا سیاست اپراتور بتواند یک ارتباط معتبر برقرار کند. یک تطابق مبهم وضعیتی برای مدیریت است، نه دلیلی برای جعل اطمینان.
وضعیت‌هایی تعریف کنید که شواهد دیرهنگام و متغیر را تحمل کنند
یک فرایند پرداخت از مجموعه کوچکی از وضعیت‌های روشن سود می‌برد، با شواهد زنجیره جدا از تصمیم پذیرش سفارش. این جدول نمونه مراحل ممکن را توضیح می‌دهد، نه نام‌های وضعیت یک سرویس خاص را. هر گذار باید دلیلی تأییدشده داشته باشد و پذیرش پرداخت باید از تحویل زیرساخت متمایز بماند.
انتقال‌های دیرهنگام، جزئی و مازاد، انقضای نقل‌قول و داده‌های زنجیره‌ای موقتاً در دسترس نبودن را بگنجانید. انقضا باعث ناپدید شدن یک انتقال واقعی نمی‌شود. یک پرداخت دیرهنگام ممکن است به بازبینی نیاز داشته باشد، نه پذیرش یا رد خودکار. اگر یک رویداد زنجیره‌ای که قبلاً مشاهده شده تغییر کند، وضعیت را تحت سیاست مستند دوباره ارزیابی کنید، نه اینکه هر اعلان ناظر را حقیقت برگشت‌ناپذیر بدانید.
| وضعیت نمونه | معنا | تصمیم بعدی |
|---|---|---|
| در انتظار | هیچ انتقال واجد شرایط تأییدشده‌ای وجود ندارد | به مشاهده فاکتور معتبر ادامه دهید |
| شناسایی‌شده | انتقال مرتبط مشاهده شد | اطمینان زنجیره و ارتباط را بررسی کنید |
| در حال تأیید | قاعده پذیرش هنوز برآورده نشده است | تا زمانی که سیاست اجازه تصمیم می‌دهد مشاهده کنید |
| بازبینی | شواهد دیرهنگام، جزئی یا مبهم | تحت سیاست اپراتور حل کنید |
| پذیرفته‌شده | پرداخت تأییدشده و تطبیق‌شده | به جریان کاری تحویل جداگانه بروید |
تلاش‌های مجدد را ایمن و قابل‌مشاهده کنید
ناظران و کارهای تطبیق پس از قطع اتصال یا راه‌اندازی مجدد فرایند دوباره تلاش می‌کنند. از یک هویت انتقال پایدار، مانند زنجیره و شناسه مناسب تراکنش یا انتقال، برای جلوگیری از اعتبارهای تکراری استفاده کنید. پیشرفت و تصمیم‌ها را ذخیره کنید تا همان رویداد بتواند بدون فراهم‌سازی سرویس دوم یا تغییر نقل‌قول پذیرفته‌شده دوباره پردازش شود.
نتیجه ناشناخته را از عملیات ناموفق تفکیک کنید. اگر یک درخواست پایین‌دستی مهلت زمانی را از دست داد، نتیجه معتبر آن را پیش از ارسال مجدد بررسی کنید. سوابق پایدار اقدامات پذیرفته‌شده و نامطمئن را نگه دارید. دسترسی به توکن‌های سفارش و شواهد داخلی را محدود کنید، در حالی که اطلاعات کافی برای بررسی یک پرداخت مورد اختلاف را حفظ می‌کنید. قابلیت اطمینان در اینجا درباره تصمیم‌های قابل‌تکرار است، نه یک انیمیشن روان در تسویه.
بدانید یک سفارش در انتظار هنوز به چه چیزی نیاز دارد
یک سفارش ممکن است در انتظار بماند زیرا انتقال مشاهده نشده است، اطمینان زنجیره موردنیاز به دست نیامده است یا ارتباط آن با فاکتور نیاز به بازبینی دارد. فاکتور و مرجع تراکنش عمومی را نگه دارید، قواعد پذیرش بیان‌شده را بررسی کنید و از فرایند کمک موردنظر سفارش استفاده کنید. به‌روزرسانی تأخیری وضعیت، به‌خودی‌خود دلیلی برای ارسال پرداخت دیگر نیست.
دستورالعمل‌ها و وضعیت تأییدشده سفارش واقعی را دنبال کنید. تأیید پرداخت باید پذیرش انتقال تطبیق‌شده را مشخص کند، در حالی که تحویل سرویس وضعیت جداگانه‌ای دارد. توکن‌های دسترسی خصوصی و اسرار کیف پول را از درخواست‌های کمک دور نگه دارید.
چک‌لیست عملی شما.
- یک نقل‌قول تغییرناپذیر ایجادشده توسط سرور را ذخیره کنید.
- زنجیره، گیرنده، دارایی و مبلغ صحیح را بررسی کنید.
- قواعد پذیرش مخصوص هر زنجیره را مستند کنید.
- برخوردهای آدرس ثابت را بدون حدس و گمان مدیریت کنید.
- از اعتبارهای تکراری و ارسال‌های مجدد ناایمن جلوگیری کنید.
- موارد دیرهنگام، جزئی، مسیر اشتباه و شواهد متغیر را آزمایش کنید.
جزئیاتی که اهمیت دارند.
آیا یک هش تراکنش برای تأیید پرداخت کافی است؟+
خیر. انتقال را روی زنجیره موردنظر، محتوای آن و اطمینان آن بررسی کنید، سپس ثابت کنید که به سفارش تعلق دارد و قبلاً اعتبار نگرفته است.
آیا هر شبکه می‌تواند از آستانه تأیید یکسان استفاده کند؟+
خیر. شبکه‌ها مدل‌های اطمینان و نهایی‌بودن متفاوتی ارائه می‌دهند. اپراتور باید یک سیاست پذیرش مناسب برای هر مسیر تعریف و آزمایش کند.
آیا پرداخت تأییدشده به معنای فراهم‌سازی سرور است؟+
خیر. پذیرش پرداخت و تحویل رویدادهای جریان کاری جداگانه‌ای هستند. وضعیت فراهم‌سازی را از فرایند معتبر خودش اطلاع دهید.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- راهنمای توسعه‌دهنده Bitcoin: رفتار بلاک‌چین developer.bitcoin.org
- Ethereum: اثبات سهام و نهایی‌بودن ethereum.org
- Solana: تعهد وضعیت RPC solana.com
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.