أنظمة تأكيد المدفوعات ونهائية المعاملات

تأكيد الدفع عتبة ثقة، وليس عدداً موحداً من الكتل

لا تصبح مدفوعات البلوكشين مكتملة تشغيلياً في لحظة واحدة تنطبق على جميع الشبكات. تظهر المعاملة أولاً للمراقبين، ثم قد تُدرج في كتلة، وتحصل على تأكيدات أقوى، وتبلغ النهائية الخاصة بالبروتوكول، ثم تستوفي سياسة قبول التاجر.

تجيب كل مرحلة عن سؤال مختلف. الرصد يثبت وجود معاملة مرشحة. التأكيد يوضح مدى دعم الشبكة لموضعها الحالي. النهائية تبين صعوبة التراجع عن ذلك الموضع. أما قبول الدفع فيسأل إن كان الدليل كافياً لتنفيذ إجراء تجاري محدد، كتسليم منتج أو إضافة رصيد.

يركز هذا التحليل على الحدود بين ثقة الشبكة وقرار التاجر. يقدم مقال Blockchain Payments النموذج الأشمل لتحويل المعاملة إلى دفعة تجارية، بينما يشرح تحليل Blockchain Consensus الأساس الذي تنتج عنه السجلات المقبولة.

مصادر هذا القسم: OxaPay · OxaPay

الرؤية والإدراج والتأكيد والنهائية والقبول حالات منفصلة

قد تستخدم المحفظة ومستكشف الكتل والعقدة وبوابة الدفع ولوحة التاجر كلمة «مؤكد» بمعانٍ مختلفة. لذلك يجب على النظام الموثوق تحديد المعنى الدقيق لكل حالة وعدم الاكتفاء بتسمية الواجهة.

1. البث: أرسلت المحفظة المعاملة الموقعة، لكن قبولها وانتشارها ليسا مضمونين.
2. الرصد: شاهد مراقب واحد أو أكثر المعاملة؛ ويمكن أن تبقى معرضة للاستبدال أو الإسقاط أو التأخير.
3. الإدراج: ظهرت المعاملة في كتلة مقترحة أو مقبولة؛ وقد تتغير أجزاء من التاريخ الحديث.
4. التأكيد: دعم البروتوكول موضع المعاملة بأدلة أقوى، مثل عمق الكتل أو أصوات المدققين أو مستوى الالتزام.
5. النهائية: أصبح التراجع بحاجة إلى إخفاق استثنائي أو هجوم مكلف اقتصادياً وفق افتراضات أمن الشبكة.
6. القبول: تحقق نظام التاجر من المبلغ والأصل والشبكة والتوقيت والطلب والمخاطر وسياسته التجارية.

يمكن أن يكون العميل محقاً عندما يرى المعاملة على الشبكة، ويكون التاجر محقاً عندما يترك الطلب معلقاً. يصف الطرفان مستويين مختلفين من الحالة بدلاً من حقيقتين متناقضتين.

مصادر هذا القسم: OxaPay

تحمي التأكيدات أساساً من تاريخ المعاملات غير المستقر والمتنافس

يمكن للعقد أن تختلف مؤقتاً حول أحدث تاريخ صحيح. وعند اقتراح كتلتين متقاربتين زمنياً، تحدد قواعد اختيار الفرع والنهائية أي سجل يصبح المرجع الذي تتبعه الشبكة.

تعني إعادة تنظيم السلسلة استبدال جزء حديث من التاريخ بفرع آخر. قد تنتقل المعاملة إلى كتلة مختلفة، أو تعود إلى الميمبول، أو تختفي من السلسلة المعتمدة إذا أصبح إنفاق متعارض مقبولاً. يقل الخطر بازدياد عمق التأكيد أو قوة إشارات النهائية.

في بيتكوين، يجعل إثبات العمل المتراكم تغيير التاريخ أصعب. يشرح المستند الأبيض انخفاض احتمال لحاق المهاجم بالسلسلة الصادقة مع تقدمها، لكنه لا يضع رقماً واحداً صالحاً لكل مبلغ. الميمبول أيضاً محلي وغير دائم؛ وقد تعود إليه معاملات كتل أُلغيت.

مصادر هذا القسم: Bitcoin Whitepaper · Bitcoin Developer Guide

تنشئ الشبكات الثقة والنهائية بآليات مختلفة جذرياً

النهائية ليست آلية واحدة. إنها أقوى ضمان بعدم رجوع التاريخ يمكن أن تقدمه الشبكة وفق بروتوكولها وافتراضات الثقة. يجب أن تعرف البنية التحتية مصدر الضمان قبل تحويله إلى سياسة تاجر.

• النهائية الاحتمالية: كلما امتد التاريخ المقبول فوق المعاملة أصبح الرجوع أقل احتمالاً وأكثر تكلفة، من دون لحظة نهائية مطلقة.
• نهائية التصويت أو نقاط التحقق: تصادق أغلبية المدققين المطلوبة على نقاط محددة، ويستلزم إلغاؤها انتهاكاً كبيراً أو خسارة اقتصادية.
• النهائية متعددة الطبقات: يحدث القبول المحلي السريع والتسوية الأقوى في مراحل مختلفة تشمل المنسق ونشر الدُفعات وإثباتاتها والسلسلة الأساسية.

تفصل إيثريوم بين اختيار رأس السلسلة ونهائية نقاط التحقق. يستخدم Gasper روابط تصويت بأغلبية ثلثي الحصة لتبرير النقاط وإنهائها. لذلك تختلف حالات الرأس وSafe وFinalized. النهائية الاقتصادية أقوى من مجرد الإدراج لكنها لا تعادل ضمان استرجاع قانوني أو مصرفي.

مصادر هذا القسم: Ethereum.org

يحتاج النظام متعدد الشبكات إلى ترجمة لغات ثقة مختلفة

لكل بلوكشين مفرداته وبُنى بياناته للتعبير عن الثقة. يمكن تقديم حالات تجارية موحدة، لكن لا يجوز تصوير ضمانات البروتوكولات وكأنها متطابقة.

توضح وثائق سولانا الفروق بين مستويات الالتزام الثلاثة وتحذر من أن المعاملة المعالجة قد تُسقط أثناء التفرعات. وتشرح وثائق TON ربط النهائية بالماستر تشين. يجب أن يحتفظ محول الشبكة بالدليل الأصلي وراء كل حالة موحدة.

مصادر هذا القسم: Solana Docs · TON Docs

تعتمد عتبة التأكيد الصحيحة على الخسارة المحتملة للتاجر

ليس المطلوب أعلى نهائية لكل دفعة، بل القدر المناسب لتنفيذ الإجراء التالي بأمان. زيادة الانتظار تقلل مخاطر الشبكة أحياناً لكنها قد تضر إتمام الشراء وسرعة التنشيط وثقة المستخدم.

• قيمة الدفع: غالباً ما تتطلب القيم الأعلى نهائية أقوى ومعالجة أكثر تحفظاً للاستثناءات.
• قابلية إلغاء التسليم: الوصول الذي يمكن إلغاؤه ليس كسلعة أُرسلت نهائياً أو ترخيص غير قابل للاسترداد.
• أدلة الشبكة: يجب ربط العمق وأصوات المدققين والتقدم ومؤشرات إعادة التنظيم بالشبكة المعنية.
• الإلحاح التشغيلي: تختلف احتياجات الشراء الفوري عن فواتير الشركات وتحويلات الخزانة.
• الاستثناءات: نقص المبلغ أو الشبكة الخاطئة أو انتهاء الطلب أو الازدواج مسائل مستقلة عن النهائية.

ستة تأكيدات عرف شائع لبيتكوين وليس قانوناً لكل التُجار والمدفوعات. قد يسمح رصيد منخفض القيمة وقابل للاسترجاع بسياسة مختلفة عن تسليم تجاري مرتفع القيمة ولا يمكن عكسه.

مصادر هذا القسم: OxaPay

يحسن رصد الميمبول سرعة الاستجابة لكنه لا ينشئ تسوية

عرض «تم رصد الدفع» قبل إدراج الكتلة يمنح العميل تأكيداً مبكراً بأن النظام يرى المعاملة. لكن استخدام هذه الإشارة نفسها لتسليم نهائي يضيف مخاطرة غير ضرورية.

لا توجد غرفة انتظار عالمية موحدة اسمها الميمبول؛ فالعقد تختلف في الاتصال والسياسة والمعاملات المرئية. يمكن أن تبقى معاملة برسوم ضعيفة أو تُسقط، ويمكن أن تتعارض مع إنفاق آخر أو تُستبدل.

قد تزيد الرسوم التنافسية احتمال الإدراج السريع، لكنها لا تثبت مطابقة الطلب ولا نهائية الدفع. وتشرح مقالات OxaPay عن الميمبول وتأخر المعاملات هذا الفرق بين فرصة الإدراج وثقة التسوية.

مصادر هذا القسم: OxaPay · OxaPay

يحوّل محرك التأكيد أدلة البروتوكول إلى قرار تجاري مضبوط

لا يصح الاعتماد على تسمية في مستكشف واحد لإطلاق تسليم الطلب. ينبغي جمع أدلة موثوقة، والتحقق من هوية الدفع، وتطبيق السياسة، وتسجيل سبب تغير الحالة.

1. المراقبة: اجمع المعاملات والكتل والتصويت والالتزام وصحة الشبكة مع المصدر والطابع الزمني.
2. تفسير السلسلة: حوّل Processed وIncluded وSafe وFinalized وعمق الكتل إلى أدلة معيارية من دون محو الفروق.
3. التحقق من الدفع: طابق الأصل والشبكة والمبلغ والوجهة والطلب والوقت؛ فحتى المعاملة النهائية قد تكون دفعة خاطئة.
4. تقييم السياسة: اربط العتبة بالقيمة وقابلية الاسترداد وصحة الشبكة والاستثناءات.
5. تغيير الحالة: نفّذ انتقالاً واحداً قابلاً للتدقيق وعديم الأثر المكرر، حتى لا يسبب استطلاع متكرر أو ويب هوك مكرر تسليماً مزدوجاً.

تتناول دراسة المراقبة في الزمن الحقيقي تعدد مصادر الرصد واستعادة الأحداث المفقودة. ويحتاج نموذج حالات الدفع إلى دراسة مستقلة. يهتم هذا المقال بالقرار الذي يربط الدليل الشبكي بالعمل التجاري.

مصادر هذا القسم: OxaPay

قد يكون تأكيد الطبقة الثانية سريعاً محلياً وأبطأ على السلسلة الأساسية

قد يتلقى مستخدم التجميع Rollup رداً فورياً من المنسق، ثم تُنشر المعاملة ضمن دفعة، ثم تكتسب قوة تسوية السلسلة الأم. هذه مراحل مختلفة ذات افتراضات ثقة مختلفة.

توثق Optimism الحالات Unsafe وSafe وFinalized. الأولى نُفذت محلياً ولم تُكتب على الطبقة الأولى، والثانية كُتبت على الأولى لكن قد تتأثر بإعادة تنظيمها، والثالثة ترتكز على تاريخ نهائي في الطبقة الأولى.

تميّز Arbitrum كذلك بين النهائية الناعمة السريعة من المنسق والنهائية الأقوى بعد نشر البيانات على الأصل. تصلح الإشارة السريعة لتحديث الواجهة، بينما قد تتطلب التسويات الكبيرة نشر الدُفعات ونهائية الأصل أو اكتمال الإثبات أو التحقق عبر الشبكات.

مصادر هذا القسم: Optimism Docs · Arbitrum Docs

الحالة الشبكية نفسها قد تبرر أفعالاً مختلفة بحسب نموذج العمل

• رصيد حساب صغير: اعرض الرصد فوراً، ثم امنح رصيداً مؤقتاً وقيّد السحب حتى نهائية أقوى.
• منتج رقمي: إذا كان التنزيل أو الترخيص غير قابل للاسترجاع، فانتظر دليلاً أقوى قبل التسليم.
• فاتورة شركات مرتفعة القيمة: اجمع بين النهائية ومطابقة الفاتورة والتدقيق اليدوي وتأكيد الخزانة.
• طلب مادي: يمكن البدء بالتجهيز عند الرصد، لكن يؤجل الشحن إلى بلوغ العتبة المحددة.
• فاتورة متأخرة أو ناقصة: حتى المعاملة النهائية قد تتطلب استكمالاً أو رداً أو عرض سعر جديداً أو مراجعة يدوية.

تقلل رسائل الحالة الواضحة شعور العميل بالتأخير، بشرط ألا يُعرض الرصد المبكر كما لو كان إتماماً غير قابل للعكس.

مصادر هذا القسم: OxaPay

توفر OxaPay حالات دفع تربط تقدم الشبكة بعمليات التاجر

إنشاء محولات لكل سلسلة وقواعد التأكيد وآليات المطابقة وإعادة المحاولة داخل كل متجر يحتاج جهداً تشغيلياً كبيراً. توفر OxaPay واجهات لإنشاء طلبات منظمة وتلقي تحديثات الحالة.

تدعم Generate Invoice API المبلغ والعملة والعمر الزمني ومعرّف الطلب وسماح نقص المبلغ وخيارات الدفع المختلط ورابط رد الاتصال. تحدد هذه الحقول سياق العمل الذي لا يوفره تأكيد البلوكشين وحده.

تميّز وثائق Webhook بين حالة Paying المبكرة وPaid اللاحقة، وتشرح التحقق من HMAC ومحاولات إعادة الإرسال. يجب على نظام التاجر التحقق من الإشعار وتخزينه ومعالجته دون أثر مكرر والرد بنجاح بعد التعامل الآمن معه.

1. حدد الطلب: أنشئ فاتورة بالقيمة والتوقيت ومعرّف الطلب وقواعد الاستثناء.
2. استقبل التحديث: استخدم الإشعارات الموثقة بين الخوادم بدلاً من اعتبار إعادة توجيه المستخدم إثباتاً.
3. نفّذ الإجراء: اربط Paid بالتسليم أو الوصول أو المحاسبة أو المراجعة بحسب سياسة التاجر.

مصادر هذا القسم: OxaPay Docs · OxaPay Docs · OxaPay Docs · OxaPay

خمسة فحوص قبل السماح لدفع بإطلاق إجراء لا رجعة فيه

1. هوية الدفع: هل الأصل والشبكة والعنوان والمبلغ والطلب صحيحة؟ النهائية لا تصحح دفعة خاطئة.
2. دليل السلسلة: ما مستوى التأكيد أو النهائية الأصلي الذي تحقق بالفعل؟
3. صحة الشبكة: هل تتقدم السلسلة بصورة طبيعية؟ التأخير أو إعادة التنظيم أو تعطل المنسق أو اختلاف المزودين قد يفرض التوقف.
4. التعرض للخسارة: ماذا تخسر المؤسسة إذا تبدلت الحالة وصعب استرداد السلع أو الأموال؟
5. انتقال مضبوط: هل ينفذ النظام الإجراء مرة واحدة مع سجل وتحقيق ومطابقة وقواعد تجاوز يدوي؟

أفضل سياسة ليست الأبطأ دائماً، بل تلك التي تحقق الحد الأدنى الآمن من الثقة للإجراء المطلوب وتتواصل بوضوح مع العميل.

اعتمد على وثائق البروتوكول للنهائية وعلى موارد OxaPay للتنفيذ

قد تتغير مصطلحات النهائية وآلياتها مع ترقيات الشبكات. لذلك يجب الاستناد إلى الوثائق الرسمية عند تصميم أو مراجعة سياسة الدفع.

• بيتكوين: المستند الأبيض ودليل P2P للاحتمالية والميمبول والتفرعات والكتل القديمة.
• إيثريوم: وثائق إثبات الحصة وGasper لاختيار الفروع والتصويت ونهائية نقاط التحقق.
• سولانا: أدوات التحقق من الدفع وRPC لحالات Processed وConfirmed وFinalized.
• TON: وثائق الدفع للرسائل غير المتزامنة والنهائية المرتبطة بالماستر تشين.
• الطبقة الثانية: وثائق Optimism وArbitrum للمنسق والنهائية الناعمة والنشر على السلسلة الأم.

للتطبيق على OxaPay راجع Invoice API وWebhooks وخدمة 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