01
اختر السجل المحفوظ والفهارس قبل التثبيت
عقدة Bitcoin Core المشذّبة لا تزال تتحقق من الكتل ولكنها تزيل ملفات الكتل الأقدم بعد التحقق للبقاء قرب هدف مُهيأ. اختر التقليم فقط إذا كان العملاء لا يحتاجون إلى بيانات كتل تاريخية عشوائية. توثق Bitcoin Core أن التقليم غير متوافق مع فهرس المعاملات الكامل، وأن العودة من التشغيل المشذّب إلى غير المشذّب تتطلب إعادة بناء وإعادة تنزيل سلسلة الكتل.
قم بإدراج كل استعلام محفظة أو مستكشف أو تطبيق أولاً، ثم قرر ما إذا كان يحتاج إلى فهرسة أو مرشحات كتل أو قراءات تاريخية. حدد حجم القرص للمتطلبات الحالية والفهارس المختارة وحالة قاعدة البيانات والسجلات وأعمال التحديث والنمو المستقبلي. لا تستخدم رقم حجم سلسلة غير مؤرخ كحد أدنى دائم.
02
تحقق من الإصدار واعزل الخدمة
نزّل من قناة إصدار Bitcoin Core الرسمية واتبع إجراء المجموع الاختباري والتوقيع الحالي. التحقق يعني التأكد من أن تجزئة الأرشيف مدرجة وأن التوقيعات تأتي من مفاتيح اخترت الوثوق بها؛ التنزيل الناجح وحده ليس دليلاً على المصدر. احتفظ بالإصدار وتاريخ التحقق والبصمات ذات الصلة في سجل التغيير.
شغّل البرنامج الخفي تحت حساب خدمة مخصص غير مميز بأذونات دليل بيانات مقيدة. حافظ على نظام التشغيل مُرقّعًا، واكشف فقط الخدمات المطلوبة وافصل إدارة العقدة عن بيانات اعتماد التطبيق. إذا كانت العقدة تحمّل أيضًا محفظة، فتعامل مع النسخ الاحتياطي للمحفظة وحفظ المفاتيح كعملية عالية الخطورة منفصلة؛ نسخة بيانات البلوكشين ليست بديلاً عن مواد المحفظة.
03
أبقِ RPC بعيدًا عن الإنترنت العام
تقول وثائق الواجهة الرسمية لـ Bitcoin Core بعدم تمكين RPC عبر الإنترنت العام. لا تشفر المصادقة الاتصال، ويمكن لـ RPC التحكم في العقدة والوصول إلى البيانات الخاصة، وعند وجود محافظ، يتسبب في خسارة مالية. أبقِه على المضيف المحلي عندما يكون ذلك ممكنًا. بالنسبة لتطبيق بعيد، استخدم مسارًا خاصًا مؤمنًا مثل VPN أو إعادة توجيه SSH وقيد كل من إمكانية الوصول إلى الشبكة وهوية نظام التشغيل.
مصادقة ملفات تعريف الارتباط هي الخيار الافتراضي المحلي المفضل عند عدم تكوين كلمة مرور RPC ثابتة. تعامل مع أي بيانات اعتماد RPC صالحة على أنها قوية؛ قوائم السماح بالطرق هي ضوابط تقليل مفيدة ولكنها ليست بديلاً عن عزل النظام. واجهة الند للند منفصلة عن RPC. إذا كنت تقبل أقرانًا واردين، انشر فقط خدمة P2P المقصودة وتحقق من جدار حماية المضيف من وثائق الإصدار الحالية.
04
تحديد قبول المزامنة
قد تستغرق المزامنة الأولية وقتًا طويلاً وتستهلك CPU والقرص والشبكة لفترة ممتدة، لذا اترك هامشًا في السعة وتجنب الوعد بوقت إكمال قبل مراقبة الأجهزة المختارة والأقران والسلسلة الحالية. راقب المساحة الحرة على القرص وإعادة تشغيل العمليات وحالة الأقران وحقول المزامنة المعروضة في وثائق RPC الحالية لـ Bitcoin Core. سجّل أفضل كتلة وحالة الرأس ومؤشر تنزيل الكتلة الأولي كدليل، لكن قارنها بحالة الشبكة الحالية بدلاً من ارتفاع ثابت.
النتيجة المتوقعة هي عقدة تبدأ تلقائيًا، ولا تبلغ عن خطأ تحقق غير محلول، وتصل إلى السلسلة الحالية وفق حقول RPC الموثقة، وتتصل بالأقران المقصودين وتعرض RPC فقط عبر المسار المعتمد. نفذ قائمة القبول هذه على العقدة المنشورة؛ إنها ليست نتيجة مُدعاة هنا.
05
خطط للصيانة والاسترداد
اشترك في إعلانات الإصدارات والأمان الرسمية، وراجع ملاحظات الإصدار قبل الترقيات، وأوقف التشغيل بشكل نظيف واحتفظ بتعليمات التراجع أو إعادة التثبيت. أنذر قبل أن تصبح مساحة القرص حرجة وأعد تقييم خيارات التقليم والفهرسة عندما تتغير متطلبات التطبيق. قد تحتاج العقدة المُقلَّمة إلى إعادة تنزيل كاملة لبعض مسارات الاسترداد، لذا أدرج وقت الشبكة وتوفر البيانات في دليل التشغيل.
قم بعمل نسخ احتياطي للتكوين ومواد المحفظة وفقًا لحساسيتها المنفصلة، لكن افترض أن حالة سلسلة الكتل يمكن إعادة بنائها من الشبكة عند الضرورة. اختبر الاسترداد دون كشف المفاتيح الخاصة أو إعادة استخدام بيانات اعتماد الإنتاج. النقل غير المقاس يمكن أن يبسط الفوترة أثناء المزامنة وتشغيل الأقران؛ لكنه لا يضمن سرعة المزامنة أو يغني عن مراقبة النطاق الترددي والموارد.
إجابات مباشرة
أسئلة حول هذا الدليل
هل لا تزال عقدة Bitcoin Core المشذبة عقدة تحقق كاملة؟
إنه يتحقق من السلسلة لكنه لا يحتفظ بجميع ملفات الكتل القديمة. هذا يحد من الوصول إلى البيانات التاريخية، ويتعارض مع txindex، ويجعل العودة إلى التشغيل غير المشذب تتطلب إعادة تنزيل سلسلة الكتل.
هل يمكنني كشف Bitcoin Core RPC بكلمة مرور قوية؟
ليس للإنترنت العام. تنص Bitcoin Core على أن مصادقة RPC لا تشفر حركة المرور وأن الواجهة ليست محصنة ضد إدخال الإنترنت العشوائي. استخدم المضيف المحلي أو مسارًا خاصًا مؤمنًا مع عزل النظام.