استضافة BTCPay Server ذاتياً على VPS: اقبل Bitcoin وLightning بدون معالج دفع

ما هو BTCPay Server فعلياً، وما الذي يحل محله

BTCPay Server ليس محفظة وليس شركة دفع. إنه طبقة البرمجيات التي تقف بين موقعك وعقدة Bitcoin الخاصة بك، وتقوم بالعمل المملّ والضروري الذي يقوم به معالج الدفع عادةً نيابةً عنك: يُنشئ عنواناً جديداً أو فاتورة Lightning لكل طلبية، ويُسعِّر مبلغاً بالعملة الورقية بسعر صرف يُثبِّته طوال عمر الفاتورة، ويراقب السلسلة بحثاً عن الدفعة، ويقرر متى تُعتبَر الدفعة مُسوّاة، ويُخبر متجرك بذلك. لا تمر الأموال أبداً عبر حساب أي أحد في طريقها إليك، لأنه لا يوجد حساب أصلاً — العناوين تخص محفظة تتحكم بها أنت، والبرنامج لا يفعل سوى مراقبتها.

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

ما تحصل عليه مقابل هذا العمل هو نقطة دفع مكتملة حقاً. فواتير بصلاحية محدودة وسعر صرف مُثبَّت. الدفع على السلسلة وLightning في الفاتورة نفسها، بحيث لا يُطلَب من عميل يدفع دولارَين دفع رسوم شبكة بثلاثة دولارات. صفحة نقطة بيع، وزر تبرع، وصفحة تمويل جماعي، وزر دفع يمكنك لصقه في أي HTML. إضافات لمنصات المتاجر الشائعة، وREST API كامل إذا كان متجرك شيئاً كتبته بنفسك. استرداد للأموال، ومدفوعات قابلة للسحب، وعمليات صرف. Payjoin، إن كنت تهتم بكسر افتراض ملكية المُدخلات المشتركة (common-input-ownership heuristic) من جهة الاستقبال.

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

الجهاز: ما يحتاجه فعلياً، وأين تتوقف الخطة الرخيصة عن الكفاية

التطبيق صغير. أما الكومة التي تحته فليست كذلك. يُشغِّل النشر الافتراضي Bitcoin Core، ومُفهرِس عناوين يُسمى NBXplorer، وقاعدة بيانات PostgreSQL، وتطبيق BTCPay على الويب، وreverse proxy يتولى الشهادات، و — إن فعَّلته — عقدة Lightning، كل واحد منها في حاوية خاصة به. تطبيق الويب سيكون سعيداً على جهاز Raspberry Pi. أما Bitcoin Core فلن يكون كذلك.

الذاكرة هي أول شيء يُقصِّر الناس في شرائه. غيغابايتان سيُشغِّلان الكومة تقنياً وسيقضيان المزامنة الأولية في المبادلة (swapping)، وهو ما يُحوِّل اليوم الواحد إلى ثلاثة أيام على NVMe مشترك. أربعة غيغابايت حد أدنى معقول للدفع على السلسلة فقط. ثمانية هي الحد الأدنى الواقعي بمجرد دخول Lightning في الصورة، لأنك تُشغِّل الآن daemon ثانياً يحتفظ بقاعدة بياناته الخاصة ورؤيته الخاصة للرسم البياني، ولأن bitcoind يعمل بشكل أفضل بكثير أثناء التنزيل الأولي حين تستطيع منحه dbcache كبيراً بدلاً من الافتراضي المتحفظ. ملاحظات reduce-memory في Bitcoin Core هي المرجع لمعرفة أي الإعدادات تُقايض RAM بالوقت.

القرص هو العامل الثاني، وهو الذي يُحدِّد خطتك. السلسلة غير المُقلَّمة تجاوزت سبعمئة غيغابايت وتضيف نحو ستين غيغابايت سنوياً، لذا لم تعد العقدة الأرشيفية تناسب أي فئة VPS نبيعها وينبغي أن تكون على جهاز مخصص حيث يترك لك زوج مرآوي تيرابايتاً كاملاً. التقليم يُغيِّر ذلك كلياً — تحتفظ العقدة بنافذة متجددة من الكتل الأخيرة وتتخلص من الباقي، وبالنسبة لنقطة دفع فذلك ليس تنازلاً على الإطلاق، لأن التاجر لا يحتاج أبداً إلى تقديم كتل تاريخية لأي أحد. أضف قاعدة بيانات المُفهرِس، وPostgreSQL، وصور Docker ووحدات التخزين الخاصة به، ومخزن عقدة Lightning الخاص بها، والسجلات، ويستقر النشر المُقلَّم بارتياح داخل فئة جهاز بمئة غيغابايت مع متسع للنمو.

المعالج (CPU) يهم أساساً لأسبوع واحد من حياتك. التحقق من التواقيع أثناء التنزيل الأولي للكتل هو أثقل ما سيفعله هذا الخادم على الإطلاق؛ بعد ذلك، فإن التحقق من كتلة واحدة كل عشر دقائق والرد على حفنة من طلبات الفواتير أقرب إلى الخمول. اشترِ أنوية من أجل المزامنة، لا من أجل حالة الاستقرار — أو اشترِ الخطة الأصغر واقبل أن تستغرق المزامنة وقتاً أطول، وهي مقايضة معقولة تماماً إن لم تكن في عجلة من أمرك.

التقليم يوفر مساحة القرص، لا الوقت — والمزامنة هي أطول خطوة

أكثر سوء فهم شائع حول تشغيل عقدة هو أن التقليم يجعلها أسرع. هذا غير صحيح. تُنزِّل العقدة المُقلَّمة كل كتلة ابتداءً من كتلة التكوين (genesis block) فصاعداً، وتتحقق من كل توقيع في كل واحدة منها، تماماً مثل العقدة الأرشيفية؛ والفرق الوحيد هو أنه بمجرد التحقق من كتلة وعدم الحاجة إليها، تُحذَف بدلاً من أن تُحفَظ. أنت توفر مساحة القرص. لا توفر شيئاً في عرض النطاق الترددي ولا شيئاً في الوقت. من يتوقع أن تكون العقدة المُقلَّمة جاهزة خلال ساعة سيقضي تلك الساعة مقتنعاً أن شيئاً ما معطَّل.

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

بعد ذلك، وبعد مزامنة السلسلة، هناك انتظار ثانٍ لا يُخطط له أحد تقريباً. حين تربط محفظة لها تاريخ بالفعل — مفتاح عام ممتد من محفظة عتاد كنت تستخدمها منذ عام — يتعيَّن على المُفهرِس مسح السلسلة بحثاً عن العناوين المُشتقة منه. على عقدة مُقلَّمة، ذلك المسح محدود بما لا يزال موجوداً على القرص، ولهذا يهم ترتيب التثبيت: وجِّه المحفظة إلى العقدة قبل أن تُحذَف الكتل القديمة إن كنت تحتاج إلى ظهور معاملات تاريخية، أو تقبَّل أن يبدأ المتجر من اليوم الحالي وتعامل مع ذلك على أنه البداية النظيفة التي عادةً ما تكون كذلك.

القاعدة العملية للجدولة هي أن يكون الجهاز في الخدمة ويُزامن قبل أن يحتاجه المتجر بوقت كافٍ. جهِّزه، وابدأ التنزيل، واقضِ اليوم الفاصل في إنجاز الأجزاء التي لا تعتمد على السلسلة: DNS، والشهادات، وإضافة المتجر، والمحفظة، وروتين النسخ الاحتياطي. إن تركت العقدة إلى الأخير ستكتشف أنك التزمت بتاريخ إطلاق تتحكم فيه عملية لا يستطيع أحد تسريعها.

المفاتيح: قرار البنية الذي تتخذه مرة واحدة

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

البديل — أن تدع BTCPay يُنشئ محفظة ساخنة ويحتفظ بها للراحة — متاح، وهو أحياناً القرار الصحيح لأحجام صغيرة جداً، وينبغي أن يكون قراراً واعياً لا شيئاً حدث لأنه كان الزر الافتراضي. إن اخترته، عامِل الرصيد على ذلك الخادم كما تُعامِل النقد في صندوق متجر: اجمعه دورياً وفق جدول، واحتفظ فقط بما يحتاجه تداول يوم واحد، وافهم أن البذرة (seed) موجودة على قرص في مركز بيانات.

Lightning هو الاستثناء الذي لا يمكن تجنبه. يجب على عقدة Lightning توقيع المعاملات في الوقت الفعلي لتحديث حالة القناة، لذا فإن مفاتيحها ساخنة بالضرورة، ولا يوجد وضع للمشاهدة فقط لا يزال يتيح لك الاستقبال. هذا ليس عيباً في BTCPay؛ إنه ما يتطلبه البروتوكول. الاستجابة الصحيحة هي أن تُحجِّم رصيد Lightning بما يناسب المهمة — ما يكفي من السعة الواردة لاستقبال طلبات يوم أو أسبوع، لا خزينتك بأكملها — ونقل المقبوضات المتراكمة إلى التخزين البارد بانتظام، وهو نفس الانضباط الذي يُطبِّقه أي متجر على صندوقه.

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

Lightning مشكلة سيولة ترتدي زي برمجية

تثبيت عقدة Lightning سهل. أما استقبال أول دفعة عليها فليس كذلك، والسبب يُوقِع في الفخ كل شخص تقريباً. قناة Lightning رصيد ذو جانبَين: حين تفتح قناة وتموِّلها، تكون كل السعة في جانبك، ما يعني أنك تستطيع الدفع للآخرين ولا يستطيع أحد الدفع لك. الاستقبال يتطلب سعة واردة — أموالاً جالسة على الجانب البعيد من قناة، جاهزة للتحرك نحوك. عقدة مُثبَّتة حديثاً بثلاث قنوات صادرة ممولة جيداً لا يمكنها مع ذلك قبول ساتوشي واحد من عميل، ولن تعرض نقطة الدفع Lightning كخيار على الإطلاق.

هناك ثلاث طرق صادقة لإصلاح ذلك. يمكنك شراء سعة واردة من مزوِّد سيولة، وهو الأسرع ويُكلِّف رسماً يتناسب مع المبلغ والمدة. يمكنك تنفيذ submarine swap — الدفع عبر Lightning والاستقبال على السلسلة، ما يُحرِّك رصيدك الخاص إلى الجانب البعيد من قنواتك ويُحوِّل الصادر إلى وارد مقابل رسم المبادلة. أو يمكنك أن تطلب من نظير جيد الاتصال فتح قناة نحوك، وهذا مجاني إن كانت لديك العلاقة وبطيء إن لم تكن. أياً كان ما تختاره، ضع له ميزانية قبل الإطلاق، وحدِّد حجمه وفق تدفق طلبياتك المتوقَّع لا باختيار رقم مستدير.

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

المكافأة مقابل هذا العناء حقيقية. رسوم السلسلة لا تهتم بحجم الدفعة، ما يجعل طلبية بخمسة دولارات غير منطقية اقتصادياً حين يكون mempool مزدحماً ومقبولة تماماً حين لا يكون كذلك — وأنت لا تتحكم في أي الحالتَين ستكون سائدة يوم إطلاقك. تُسوَّى مدفوعات Lightning في أقل من ثانية مقابل جزء من السنت بصرف النظر عن الازدحام، وبالنسبة لأي شيء مُسعَّر مثل قهوة، أو تنزيل، أو شحن رصيد API، أو اشتراك شهري، فإن ذلك هو الفارق بين نقطة دفع تعمل وأخرى تخسر البيع بهدوء.

النسخة الاحتياطية التي تُدمِّرك: لا تُرجِع عقدة Lightning إلى الوراء أبداً

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

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

لذا فالقاعدة مطلقة وتستحق أن تُكتَب على الحائط: لا تستعِد عقدة Lightning أبداً إلى حالة سابقة. لا من لقطة نظام ملفات، ولا من تفريغ قاعدة بيانات، ولا من نسخة من مجلد البيانات أخذتها الأسبوع الماضي، ولا من اللقطات الساعية التي تأتي مع الخادم. اللقطات ممتازة لبقية الجهاز وخطيرة تحديداً على هذا المجلد، والخطر صامت — ستبدأ العقدة، وتبدو سليمة، وتُكلِّفك مالاً لاحقاً.

ما تحتفظ به بدلاً من ذلك هو نسخة احتياطية ثابتة للقناة (static channel backup): ملف صغير، يُحدَّث كلما فُتحت قناة أو أُغلقت، يحتوي على معلومات كافية بالضبط لتطلب من كل طرف مقابل الإغلاق تعاونياً وإعادة أموالك. يُسمِّيه LND channel.backup ويُوثِّق دلالاته في دليل الاسترداد الخاص به؛ ويُقدِّم Core Lightning ما يعادله إلى جانب إضافة تحتفظ بنسخة مُكرَّرة باستمرار من قاعدة البيانات. استعادة واحدة من هذه لا تُتابع قنواتك — بل تُغلقها كلها إغلاقاً قسرياً وتسترد الرصيد، وهي النتيجة الصحيحة والآمنة الوحيدة بعد خسارة كاملة. احفظها خارج الجهاز، وأبقِها محدَّثة، وافهم أنها وثيقة تأمين، لا زر استئناف.

أما كل شيء آخر، فخذ نسخاً احتياطية بشكل طبيعي وسخي. يأتي نشر BTCPay مع سكربت نسخ احتياطي خاص به يُوقِف الكومة، ويُفرِّغ قاعدة البيانات والإعداد بشكل متسق، ثم يُعيد تشغيلها؛ شغِّله وفق جدول وانسخ الناتج إلى مكان آخر، ويُفضَّل أن يكون خادماً ثانياً في ولاية قضائية مختلفة. تحتفظ قاعدة البيانات بفواتيرك، ومتاجرك، ومستخدميك، ومفاتيح API، والإعدادات — لا أموالك، لكن كل تاريخك، وهو ما ستفتقده فعلياً.

مكان وجود الخادم جزء من كومة الدفع

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

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

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

الثالثة هي الدفع مقابل الاستضافة نفسها، وهي الحلقة التي يتركها معظم الناس مفتوحة. تشغيل نقطة دفع مجهولة وغير حارسة للأموال على خادم يُدفع ثمنه ببطاقة ائتمان باسمك الحقيقي يخلق بالضبط الرابط الذي بنيت بقية الكومة لتجنبه. الدفع مقابل الجهاز بـMonero أو Bitcoin يُغلق تلك الحلقة — نفس المنطق، مُطبَّقاً طبقة أعمق. يعني ذلك أيضاً أن فاتورة البنية التحتية لا يمكن أن يقطعها نموذج مخاطر خاص بمُصدِر بطاقة، وهو نمط فشل أخرج متاجر من الخدمة فعلياً.

أخيراً، متطلبات الموثوقية المملة أكثر صرامة هنا منها لمدونة. عقدة Lightning غير متصلة لا تستطيع الاستقبال، ولا مراقبة طرف مقابل غشاش، وقد يُغلقها نظراء لا يستطيعون الوصول إليها إغلاقاً قسرياً. عقدة Bitcoin تتخلف عن السلسلة تُظهر للعملاء فواتير لا تستطيع تسويتها. عرض النطاق الترددي غير المُقاس يهم أكثر مما يبدو، لأن عقدة تُشارك فعلياً في الشبكة تُقدِّم الكتل للنظراء، وستُقدِّم لك خطة مُقاسة فاتورة لا علاقة لها بحركة مرور متجرك.

ترتيب التثبيت الذي يتجنب مزامنة ثانية

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

ابدأ بجهاز نظيف وسجل DNS. يطلب المُثبِّت شهادة لاسم المضيف الذي تُعطيه له، ويخرج ذلك الطلب إلى جهة إصدار شهادات ستتصل بعنوانك عبر المنفذ 80. إن لم يكن السجل مُحلَّلاً بعد، أو كانت المنافذ مغلقة، تعمل الكومة بلا TLS ويتوجب عليك معرفة أي من ثلاثة أشياء فشل. أنشئ سجل A، وتأكَّد من أنه يُجيب من مكان ليس حاسوبك المحمول، وافتح المنفذَين 80 و443، وعندها فقط شغِّل المُثبِّت.

قرِّر المقتطفات قبل أول تشغيل، لا بعده. تُخبِر البيئة المُولِّد بالسلاسل التي تُفعِّلها، وتنفيذ Lightning الذي تستخدمه، وما إذا كنت ستُقلِّم وبأي قدر من الصرامة، وما إذا كنت ستُعرِّض خدمة onion إلى جانب مضيف الشبكة العادية (clearnet)، وreverse proxy الذي تضبطه. تغيير بعض هذه لاحقاً رخيص؛ أما التي تلمس العقدة — تفعيل سلسلة، أو تشغيل التقليم أو إيقافه، أو تبديل تنفيذ Lightning — فتعني إعادة تنزيل أو إعادة فهرسة شيء ما، وإعادة تنزيل شيء ما هو ما يُكلِّف يوماً كاملاً. اقرأ قائمة المقتطفات مرة واحدة، واختر بوعي، ثم شغِّلها.

بينما تُنزَّل السلسلة، أنجز البقية. أنشئ متجرك واضبط عملته، وصلاحية فاتورته، وكم عدد التأكيدات التي تريدها قبل أن تُعتبَر الفاتورة مُسوّاة — قرار يستحق اتخاذه بوعي، لأن القبول بلا تأكيد سريع وخاطئ أحياناً، وستة تأكيدات آمنة وتستغرق ساعة. استورد المحفظة للمشاهدة فقط. ثبِّت إضافة المتجر ووجِّهها إلى الخادم بمفتاح API محدود النطاق لا بحساب المسؤول. اضبط مصدر سعر الصرف. أرسل لنفسك فاتورة اختبار بمبلغ زهيد وادفعها، على السلسلة وعبر Lightning، من محفظة ليست على الجهاز نفسه — عدد عمليات النشر التي لم تُختبَر قط ولو مرة واحدة بمال حقيقي أكبر مما يتمناه أي أحد.

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

تحصين جهاز يحمل أموالاً

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

أبقِ واجهة الإدارة بعيدة عن الإنترنت العام إن استطعت. لوحة تحكم BTCPay هي مستوى التحكم في أموالك — تستطيع إنشاء مدفوعات قابلة للسحب، وتغيير المحافظ، وإصدار مفاتيح API — ولا تحتاج إلى أن تكون قابلة للوصول من العالم بأسره لمجرد أن صفحات الفواتير تحتاج ذلك. ربط مسار الإدارة خلف VPN أو خدمة onion، أو خلف قائمة سماح، يُزيل فئة كاملة من المخاطر مقابل خطوة إضافية واحدة في سير عملك. نفق WireGuard إلى الخادم هو أقل نسخة تطفلاً من هذا.

عامِل مفاتيح API كبيانات الاعتماد الأساسية لا كفكرة لاحقة، لأنها عملياً الطريقة التي يتحدث بها المتجر إلى نقطة الدفع والطريقة التي سيستخدمها مهاجم أيضاً. أصدِر مفتاحاً واحداً لكل تكامل، وحدِّد نطاقه للمتجر والصلاحية التي يحتاجها فعلياً، واحفظه في إعداد المتجر السري لا في مستودع، وبدِّله حين يغادر أحدهم. مفتاح غير محدود النطاق على مضيف ويب مُخترَق مماثل عملياً لتسليم لوحة التحكم.

راقب حالتَي الفشل الفريدتَين لهذه الكومة، لأن أياً منهما لا يبدو كانقطاع خدمة. عقدة توقفت عن متابعة السلسلة ستستمر في خدمة الموقع وستستمر في إظهار فواتير للعملاء لا يمكن تسويتها أبداً. عقدة Lightning فقدت الاتصال بنظرائها ستستمر في قبول الطلبيات على السلسلة بينما ترفض بهدوء كل دفعة عبر Lightning. راقب ارتفاع الكتلة (block height) مقابل مرجع عام، وراقب عدد القنوات والرصيد الوارد، ونبِّه على الاثنَين — هذه هي المراقبة التي لا يُعِدُّها أحد حتى المرة الأولى التي تُكلِّفه فيها يوماً من الطلبيات.

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

Monero والعملات التي لا يتحدث BTCPay لغتها بمفرده

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

Monero هو ما يسأل عنه الناس أكثر من غيره، وهو يعمل فعلاً — عبر إضافة مدعومة بـmonerod الخاص بك وdaemon لـRPC المحفظة، يعمل إلى جانب كومة Bitcoin. التصميم نفسه كتصميم Bitcoin في الجوانب المهمة: أنت تُشغِّل العقدة، وأنت تحتفظ بالمفاتيح، والبرنامج يراقب المدفوعات. ما يختلف هو التكلفة التشغيلية. إنها سلسلة كتل ثانية يجب تنزيلها وإبقاؤها مُزامَنة، وdaemon ثانٍ يجب مراقبته وتحديثه، والإضافة يصونها المجتمع لا الفريق الأساسي، ما يعني أن وتيرة إصداراتها خاصة بها. إن كان Monero مجرد إضافة لطيفة لا أكثر، فزِن ذلك بصدق؛ وإن كانت الخصوصية عند نقطة البيع هي السبب الكامل لمجيء عملائك، فالأمر يستحق العناء، والمقارنة بين السلسلتَين تُوضِّح ما تُخفيه كل واحدة منهما فعلياً.

القاعدة العامة لأي سلسلة إضافية هي أن تسأل عمَّا تُكلِّفك حين تتعطل. كل سلسلة تُفعِّلها هي عقدة يمكن أن تتخلف عن الركب، ومحفظة تحتاج نسخاً احتياطياً، ومصدر سعر صرف يمكن أن يصبح قديماً، ومحادثة دعم مع عميل عالقة دفعته. طريقتا دفع تُداران جيداً أفضل من ست طرق مُهمَلة، ونقطة دفع تعرض عملة توقفت عقدتها عن المزامنة منذ أسبوع أسوأ من واحدة لم تعرضها قط.

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

ما يُكلِّفه هذا، مقابل ما يتقاضاه معالج الدفع

الحساب سهل بشكل غير معتاد، لأن نقطة الدفع ذاتية الاستضافة لها تكلفة ثابتة وبلا نسبة مئوية. عقدة Bitcoin مُقلَّمة مع Lightning تتسع على خطة بعشرات الدولارات القليلة شهرياً؛ ومتجر أكثر ازدحاماً يريد هامشاً أكبر يقع فئة أو فئتَين فوق ذلك. تُكلِّف المدفوعات على السلسلة رسم الشبكة، الذي يدفعه العميل، وتُكلِّف مدفوعات Lightning رسم توجيه يُقاس بأجزاء من السنت. لا توجد عمولة لكل معاملة، ولا حد أدنى شهري، ولا تأخير في التسوية، ولا فئة حسب الحجم.

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

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

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

متى ينبغي ألا تستضيف هذا بنفسك

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

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

وإن كان عبء عملك متذبذباً بشكل يجعل التوقف كارثياً — إطلاق، أو إصدار محدود، أو حملة تمويل بموعد نهائي — ففكِّر مليّاً قبل أن تجعل أول نشر ذاتي الاستضافة لك مرهوناً بذلك الموعد النهائي. شغِّله بالتوازي مع شيء آخر لدورة كاملة، واقبل مدفوعات حقيقية عبره بحجم منخفض، ودعه يُثبت جدارته قبل أن يتحمَّل عبء اليوم الذي يهم فعلاً. نقله لاحقاً مشكلة محلولة؛ أما اكتشاف أنماط فشله أثناء أكثر ساعاتك ازدحاماً فليس كذلك.

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

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