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

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

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

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

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

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

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

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

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

تعود هذه الفلسفة إلى مقال كين تومبسون عام 1984 Reflections on Trusting Trust، الذي حذّر من أنه حتى كود مصدر يبدو نظيفًا لا يمكن الوثوق به إذا كان المُصرّف (الـ compiler) الذي بنى ذلك البرنامج نفسه قد تم اختراقه. أخذ مطورو Bitcoin Core هذا الدرس على محمل الجد. وبحسب كلمات مساهم Bitcoin Core مايكل فورد (fanquake):

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

تصريح يجمع بين كونه هدفًا تقنيًا وجزءًا من روح Bitcoin.

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

البنيات القابلة لإعادة الإنتاج: تحقق من الأسفل إلى الأعلى

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

“الأطراف الثالثة الموثوقة هي ثغرات أمنية” – Nick Szabo (2001)

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

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

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

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

لن يقوم أغلب الناس بإجراء تجميع كامل أو التحقق من manifests الخاصة بـ Guix أو مقارنة هاشات البناء. لا يحتاجون إلى ذلك. إن وجود هذه البنية التحتية والأشخاص الذين يقومون على صيانتها يمنح كل مستخدم أساسًا من الثقة المكتسبة.

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

إنها عملية تحقق من الأسفل إلى الأعلى.

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

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

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

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

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

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

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

عدم وجود تحديثات تلقائية

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

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

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

التكامل المستمر: التحرك ببطء وإصلاح الأمور

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

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

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

تحرك ببطء وأصلح الأمور.

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

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

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

مفارقة البنيات القابلة لإعادة الإنتاج هي أنها تتطلب تطورًا مستمرًا لتظل قابلة لإعادة الإنتاج. يجب على المطورين تثبيت (pin) الأدوات باستمرار وتصحيحها (patch) وأحيانًا استبدال toolchains للحفاظ على الحتمية في ظل واقع متغير. الحفاظ على هذا التوازن بين الاستقرار والقدرة على التكيف جزء من مرونة Bitcoin المستمرة.

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

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

هذه القطعة هي رسالة من المحرر (Letter from the Editor) المميزة في أحدث طبعة Print من Bitcoin Magazine، The Core Issue. نحن نشاركها هنا كتقديم مبكر للأفكار التي تم استكشافها طوال العدد الكامل.

[1]