Bitcoin: A Work in Progress كتاب للمطور Sjors Provoost عن تطور Bitcoin تقنيًا. يشرح مشكلات لا يراها المستخدم عادة: كيف تقرأ المحفظة العنوان، وكيف تصل أخبار الشبكة إلى العقدة، ولماذا يتطلب حتى التغيير الصغير حذرًا.
يمكنك استخدام Bitcoin دون معرفة شيفرته البرمجية. لكن ذلك لا يعني أنه لم يعد هناك ما يستحق التحسين. يقرّب Sjors Provoost، المساهم في Bitcoin Core، القارئ من العمل الذي يسمح للشبكة بالتطور. صدرت الطبعة الورقية الأولى عن Purple Dunes عام 2022. يتناول الكتاب مسائل تقنية من زمنه؛ وتعديل ملفات المصدر لاحقًا لا يغيّر تاريخ النشر الأول. [1] [2]
تخيّل أن صديقًا أرسل إليك عنوانًا فألصقته في محفظتك. بالنسبة إليك، هذه بداية دفعة. أما المطور فيفكر أيضًا في كشف خطأ الكتابة وإبلاغ المحفظة بوجهة الدفع دون التباس. هذا مثال وضعناه نحن لتقديم مدخل إلى الكتاب دون اشتراط معرفة البرمجة. ينتقل محتواه من العناوين إلى تواصل العقد ثم تغيير القواعد. تصبح الفصول الأصعب أوضح بعد فهم هذه الأسس. [2]
العنوان صيغة تستخدمها المحفظة لبناء شروط إنفاق مبلغ لاحقًا. تُكتب هذه الشروط في مخرج معاملة، أي جزء جديد تنشئه الدفعة. ولإنفاقه فيما بعد، يجب إثبات استيفاء الشروط، عادةً بتوقيع رقمي صالح. لذلك لا تحتاج الشبكة إلى إدارة حساب مصرفي باسمك. يساعد فصل Provoost على التمييز بين العنوان الذي يتبادله الناس والقواعد التي تتحقق منها الحواسيب. [3]
يتضمن العنوان قيمة تحقق تساعد المحفظة على اكتشاف أخطاء النسخ. لكنها لا تحدد صاحب العنوان. في مثالنا، قد تلصق بالخطأ عنوان شخص آخر مكتوبًا بصورة صحيحة، فيجتاز الفحص. لذا يجب التحقق أيضًا من المستلم المقصود. وإذا أبلغتك المحفظة بوجود خطأ، فمن الأسلم الحصول على العنوان الصحيح مجددًا بدل تخمين الحرف الذي ينبغي إصلاحه. [3] [4]
هنا ننتقل إلى تفصيل تقني: Bech32 وBech32m صيغتان لترميز العناوين. يحدد BIP 350 استخدام Bech32 للعناوين الأصلية ذات إصدار witness رقم 0، واستخدام Bech32m للإصدارات من 1 إلى 16. إصدار witness رقم يميز قواعد التحقق المطبقة على هذا النوع من المخرجات. تعالج الصيغة الأحدث ضعفًا في قيمة التحقق عند إدراج محارف. ولا يعني هذا أن جميع العناوين القديمة أصبحت غير صالحة أو أن على المستخدم تحويلها يدويًا. [4]
العقدة برنامج متصل بشبكة Bitcoin؛ وتتحقق Full Node بنفسها من قواعد المعاملات والكتل. لكنها تحتاج إلى تلقي البيانات الجديدة من جهة ما. في Eclipse Attack، يسيطر المهاجم على جميع اتصالات العقدة ويمكنه إخفاء جزء مما يجري في الشبكة. تظل العقدة ترفض الكتل غير الصالحة، لكن معلوماتها تكون ناقصة. يبين الكتاب فرقًا مهمًا: التحقق من البيانات المستلمة لا يعني الوصول إلى كل البيانات اللازمة. [5]
لا يستطيع المهاجم أن يفرض على العقدة المعزولة أي كتلة يشاء. لتقديم تأكيد صالح لدفعته، يحتاج أيضًا إلى كتلة صالحة تستوفي Proof of Work، أي الدليل الحسابي المطلوب على العمل. وبعد استعادة الاتصال، قد تكتشف العقدة فرعًا صالحًا آخر تراكم فيه عمل أكثر. تنتقل إليه، وإذا لم تتضمن تلك السلسلة الدفعة الأصلية فلن يعود تأكيدها السابق قائمًا. لذلك يجمع الأمان بين التحقق من القواعد واتصالات شبكية قادرة على مقاومة الهجمات. [5]
ابدأ بسؤال تعرفه من تجربتك، مثل العنوان. ثم تتبّع ما يتيحه الحل وأين تنتهي قدرته. يعتمد هذا العرض على بيانات النشر والفهرس الرسمي ومقاطع عامة مختارة عن العناوين وEclipse Attack، إضافة إلى BIP 350. وليس مراجعة للكتاب كله أو للبودكاست الذي استند إليه. يجب التمييز بين أرقام الشبكة وحالة التطوير في تلك الفترة وبين البرمجيات الحالية. [1] [2] [3] [4] [5]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Bitcoin Core, Taproot, قواعد الإجماع, محفظة.
01هل أحتاج إلى البرمجة لأتعلم شيئًا من الكتاب؟+
لا تحتاج إلى البرمجة لفهم الأسئلة المتعلقة بالعناوين أو عزل العقدة. لكن الكتاب يتضمن أيضًا فصولًا تقنية متقدمة. ابدأ بموقف مألوف وأضف التفاصيل تدريجيًا؛ فهذا العرض يشرح موضوعات مختارة فقط.
02هل يضمن عنوان صحيح وFull Node خاصة بي دفعة آمنة؟+
كل منهما يعالج مشكلة مختلفة. قيمة التحقق لا تتحقق من المستلم، وتشغيل عقدتك لا يلغي الحاجة إلى استقبال بيانات الشبكة. التحقق من العنوان والالتزام بالقواعد والتأكيد في السلسلة أمور مترابطة، لكنها لا تحل محل بعضها.