المشكلة الأساسية: وراء الثنائية، التحقق من الثقة

عندما يقوم معظم الناس بتنزيل Bitcoin Core، فإن تفاعلهم مع نظام البناء ينتهي في بضع نقرات. إنهم يقومون بتحميل الملف القابل للتنفيذ للبرنامج، والتحقق من توقيع (نأمل!)، ويبدؤون تشغيل عقدة بيتكوين. ما يرونه على الفور هو برنامج قيد التشغيل. ما لا يرونه هو نظام البناء والعمليات الواسعة التي أنتجت ذلك البرنامج. نظام بناء يمثل مبادئ بيتكوين من اللامركزية، والشفافية، والقابلية للتحقق.

وراء ذلك التنزيل يكمن سنوات من العمل الهندسي المصمم للإجابة على سؤال بسيط: “لماذا يجب على أي شخص أن يثق بهذا البرنامج؟” الجواب هو: لا يجب عليك أن تثق. يجب أن تكون قادرًا على التحقق.

في وقت تهيمن فيه هجمات سلسلة التوريد البرمجية على العناوين الرئيسية العالمية، من حزم npm المخترقة، والمكتبات ذات الأبواب الخلفية، وخوادم CI المارقة، فإن عملية بناء Bitcoin Core تقف كمشروع هادئ من الانضباط. قد تبدو طرقه بطيئة ومعقدة مقارنةً بالراحة السلسة لـ “الدفع للنشر”، لكن هذه هي النقطة. الأمن ليس مريحًا.

لفهم نظام بناء Bitcoin Core، يجب أن نفهم:

• فلسفة نظام بناء Bitcoin Core
• البناء القابل لإعادة الإنتاج
• تقليل الاعتماديات
• لا تحديثات تلقائية
• التكامل المستمر
• التكيف المستمر

فلسفة نظام بناء Bitcoin Core

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

مبدأ واحد في نظام بيتكوين هو “لا تثق، تحقق”. تشغيل عقدتك الخاصة هو فعل تحقق، يتحقق من كل كتلة ومعاملة ضد قواعد الإجماع. لكن نظام البناء نفسه يمنحك فرصة أخرى للتحقق، على مستوى البرنامج. بيتكوين هو المال بدون وسطاء موثوقين وBitcoin Core يعمل ليكون برنامجًا بدون بناة موثوقين. يبذل نظام البناء جهودًا كبيرة لضمان أن أي شخص، في أي مكان، يمكنه إعادة إنشاء نفس الملفات التنفيذية التي تظهر على موقع bitcoincore.org بشكل مستقل.

تعود هذه الفلسفة إلى مقال كين طومسون عام 1984 “تأملات حول الثقة في الثقة”، الذي حذر من أنه حتى الكود المصدري الذي يبدو نظيفًا لا يمكن الوثوق به إذا كان المترجم الذي أنشأ ذلك البرنامج قد تم اختراقه. أخذ مطورو بيتكوين هذه الدروس على محمل الجد. في كلمات مساهم Bitcoin Core، مايكل فورد (fanquake):

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

بيان هو كهدف تقني وجزء من فلسفة بيتكوين.

في عالم الأمن، يتحدث الناس عن “أسطح الهجوم”. يعامل نظام بناء Bitcoin Core عملية البناء نفسها كسطح هجوم يجب تقليله والدفاع عنه.

البناء القابل لإعادة الإنتاج: التحقق حتى النهاية

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

“الأطراف الخارجية الموثوق بها هي ثغرات أمنية” - نيك سابو (2001)

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

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

ثم يقوم المساهمون بتوقيع الملفات التنفيذية الناتجة بشكل تشفيري ونشر تلك التوقيعات في مستودع GitHub منفصل ‘guix.sigs’ الذي يسرد هذه الشهادات لكل إصدار من Bitcoin Core. بعض البنائين هم مطورو Bitcoin Core، لكن هذا ليس شرطًا حيث إن عملية الشهادة مفتوحة لأي شخص من الجمهور. في الواقع، يساهم العديد من غير المساهمين في الشيفرة بانتظام بالتوقيعات.

تُعرف هذه العملية بالبناء القابل لإعادة الإنتاج، وهي الترياق لـ “الثقة في الثقة” لطومسون. يعني أنه يمكن لأي شخص أخذ الكود مفتوح المصدر، نفس بيئة Guix، والتحقق بشكل مستقل من أن الملف التنفيذي الرسمي يتطابق مع ما بنوه بأنفسهم. بينما يمكن للبناء القابل لإعادة الإنتاج التحقق من أن البرنامج هو تمثيل حقيقي لكود البرنامج المصدر، فإن صحة البرنامج تُترك للعمليات المحيطة بالاختبار الشامل ومراجعة الكود.

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

الملفات التنفيذية الرسمية على bitcoincore.org ليست مجرد “تم إنتاجها بواسطة القائمين على Bitcoin Core”. إنها تقاطع مخرجات عشرات البنائين المستقلين. ما تقوم بتنزيله في النهاية هو ما بناه الآخرون وتحققوا من صحته.

إنه تحقق حتى النهاية.

تقليل الاعتماديات: أقل مما يجب الوثوق به

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

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

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

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

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

في عالم يزداد فيه تحميل معظم البرمجيات وزيادة اعتمادها على نظم الحزم المركزية، يتحرك Bitcoin Core في الاتجاه المعاكس: نحو الحد الأدنى والاستقلال.

لا تحديثات تلقائية

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

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

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

التكامل المستمر: انتقل ببطء واصلح الأشياء

في وادي السيليكون، يُعتبر التكامل المستمر والنشر المستمر (CI/CD) من سمات تطوير البرمجيات الرشيقة. شحن بسرعة. تكرار أسرع. دع الأتمتة تقوم بالباقي.

يتبنى Bitcoin Core نهجًا مختلفًا. أنظمة CI الخاصة به موجودة ليس لتسريع النشر ولكن لحماية النزاهة. تختبر البناء الآلي التناسق عبر المنصات. تم تصميم نظام بناء Bitcoin Core ليكون محايدًا قدر الإمكان تجاه الأجهزة وأنظمة التشغيل. يمكن للمشروع بناء ملفات تنفيذية لـ Linux وmacOS وWindows فضلاً عن عدة معماريات بما في ذلك x86_64 وaarch64 (ARM) وحتى riscv64. يضمن نظام التكامل المستمر هذه التوافق وكذلك نزاهة البرمجيات من خلال إجراء المئات من الاختبارات لكل تغيير مقترح.

النتيجة هي ثقافة حيث يعني “التكامل المستمر” الاختبار المستمر، والتحقق، والأمان، وليس الابتكار المستمر.

انتقل ببطء واصلح الأشياء.

التكيف المستمر: هل انتهينا بعد؟

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

بينما يسعى نظام بناء Bitcoin Core إلى الحتمية، لا يمكن أن يظل النظام ثابتًا. العالم الذي يعمل فيه يتغير باستمرار. تتغير أنظمة التشغيل، والمترجمات، والمكتبات، والمعماريات. كل إصدار جديد من macOS أو glibc، كل إلغاء لإشارة مترجم، أو ظهور معمارية CPU جديدة يقدم عدم توافق دقيق يجب معالجته. نظام بناء توقف عن الحركة سيتوقف بمرور الوقت عن البناء تمامًا.

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

احصل على نسختك من The Core Issue اليوم!

لا تفوت فرصتك لامتلاك The Core Issue — الذي يتضمن مقالات كتبها العديد من مطوري Core يشرحون المشاريع التي يعملون عليها بأنفسهم!

هذه القطعة هي رسالة من المحرر التي ظهرت في أحدث إصدار مطبوع من Bitcoin Magazine، The Core Issue. نحن نشاركها هنا كلمحة مبكرة عن الأفكار المستكشفة في جميع أنحاء العدد الكامل.

[1]