Bitcoin Development Philosophy كتاب متاح للعامة عن أسباب القرارات والمفاضلات في تطوير Bitcoin. مؤلفه الرئيسي Kalle Rosenbaum، وشاركته التأليف Linnéa Rosenbaum؛ وقد طلبت Chaincode Labs العمل وموّلته. يخاطب قارئًا يعرف الأساسيات التقنية ويريد تقييم مقترحات التغيير بصورة أدق.
قد يضعف المقترح النظام كله دون أن يتضمن خطأ برمجيًا. فقد يسهّل الاستخدام بإسناد جزء من التحقق إلى خدمة خارجية. يساعد الكتاب على تسمية ما نكسبه بهذه المقايضة، وتحديد الجهة التي نبدأ بالوثوق بها. يربط المؤلفان الشرح بالنقاشات السابقة وإسهامات مطورين متمرسين. وهكذا يتعلم القارئ تقييم أسباب المقترح، لا اختيار طرف لمجرد أن اسمًا معروفًا يؤيده. [2]
يفترض الكتاب فهم Proof of Work، أي العمل المُثبت في التعدين، وبناء الكتل، ومسار المعاملة من بثها حتى إدراجها في السلسلة. ثم يعرض 9 فصول رئيسية: اللامركزية، وTrustlessness، والخصوصية، ومحدودية المعروض، والترقيات، وAdversarial thinking، والتطوير المفتوح، والتوسع، ومعالجة الحوادث. ليس هذا أول دليل لشراء البيتكوين؛ بل ينطلق من الأساسيات ليسأل عن أهمية قواعد وممارسات محددة. [2] [1]
لا تعني Trustlessness ألّا تثق بأحد بعد اليوم. كما يوضح Pieter Wuille في الاقتباس الوارد، المقصود هو قدرة البروتوكول على العمل دون وسيط موثوق. يستطيع Full Node، أي عقدة تجري التحقق الكامل، أن يفحص بنفسه ما إذا كانت كتلة واردة تُنشئ عملات غير مسموحة أو تنفق المبلغ نفسه مرتين. من دون تحققك الخاص، تسند هذه المهمة إلى غيرك. لكن العقدة تظل تعمل على برامج وعتاد معينين قد يحتويان على عيوب. [3]
تخيّل دفعة مسجلة في كتلة، ثم يستبدل بها فرع آخر صالح من السلسلة. يسمى هذا التغيير في السجل إعادة تنظيم، وقد يغيّر حالة الدفعة. يستند الفصل إلى David Harding للفصل بين فحص القواعد والحماية من هذا الخطر. زيادة التأكيدات تعني إضافة كتل أخرى بعد كتلة الدفعة، وهو ما يصعّب استبدالها عادة. لكنها ليست وعدًا بأن عقدتك ستمنع كل إعادة كتابة للتاريخ. [3]
قبل التحقق من المدفوعات يأتي سؤال آخر: هل يطابق البرنامج المنزّل الشيفرة المصدرية المنشورة؟ يتيح البناء القابل لإعادة الإنتاج لأشخاص مختلفين إنتاج الملف نفسه من المدخلات نفسها. وتساعد المقارنة على فحص البرنامج الذي يُوزّع. لكن الفصل يستحضر أيضًا شرح Carl Dong: أصل الأدوات المستخدمة في بنائه مهم بدوره. تطابق الملفات لا يثبت خلو الشيفرة أو المترجم أو الحاسوب من العيوب. [3]
تعني Adversarial thinking دراسة المقترح من منظور الخصم. لا نسأل فقط هل يعمل مع مشاركين صادقين، بل ما الذي قد يكسبه مهاجم من إساءة استخدامه. يناقش الفصل افتراضات الأمان بالاستناد إلى Andrew Poelstra وJameson Lopp. من أمثلته عزل عقدة عن الشبكة الصادقة أو تعمّد تعطيل التعاون المفتوح. عمل النظام حتى الآن ليس، وحده، برهانًا رسميًا على أمان النظام بأكمله. [4]
تنطلق مسلّمة المقاومة التي يقتبسها الكتاب عن Eric Voskuil من افتراض أن نظامًا يستطيع مقاومة سيطرة الدولة. المسلّمة هنا نقطة انطلاق للاستدلال، وليست نتيجة اختبار تثبت حصانة Bitcoin. والفرق مهم للقارئ العادي أيضًا: جدوى البحث عن حل متين لا تعني أن كل حل نبتكره سيقاوم كل شيء. يقدم الكتاب طرقًا لاكتشاف هذه الافتراضات وتقليل الجوانب التي نغفلها. [4]
اسأل عند كل ادعاء: ما الذي نتحقق منه، وما الذي يبقى افتراضًا، وأي سهولة يكسبها المستخدم من التغيير؟ يربط المؤلفان النص بمقالات ومحاضرات، ويحفظان نسخ المقالات مع بيانات مصادرها في مجموعة منفصلة بالمستودع. يعتمد هذا العرض على المقدمة كاملة والنصين الكاملين لفصلي Trustlessness وAdversarial thinking. أما الفصول الأخرى فوصفناها وفق المحتويات؛ وليس هذا مراجعة للكتاب كله وروابطه، ولا تدقيقًا أمنيًا أجريناه. [2] [3] [4]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Bitcoin Core, قواعد الإجماع, Soft Fork, Full Node.
01هل يصلح كتابًا أول لمبتدئ تمامًا؟+
يناسب أكثر من قرأ مقدمة تقنية أولية. افهم أولًا المعاملة والكتلة وProof of Work. عندها يساعدك على إدراك أن إضافة ميزة مريحة لا تعني انتهاء التطوير. لا يحل محل مواصفات البروتوكول أو دورة عملية جرّبنا تمارينها هنا.
02هل تعني Trustlessness أنني لم أعد بحاجة إلى الثقة بشيء؟+
لا. تتيح عقدتك التحقق من قواعد Bitcoin بدل الاعتماد على ادعاءات الآخرين. تظل تستخدم برامج وعتادًا، وتحتاج إلى احتساب خطر إعادة تنظيم السلسلة. المهم معرفة أي اعتماد قلّلته بالتحقق وأي اعتماد بقي قائمًا.