Soft Fork

لنتخيّل آنا وبافل، اللذين يتحقق كل منهما من Bitcoin على حاسوبه الخاص. حدّثت آنا برنامجها، بينما لم يفعل بافل ذلك بعد. يصل تغيير شبيه بـ BIP66: التوقيع الرقمي، الذي يثبت صلاحية إنفاق بيتكوينات معينة، يجب أن يُكتب بصيغة أكثر تحديداً. لم تعد بعض طرق الترميز المقبولة سابقاً مسموحة. دفعة تحمل توقيعاً صحيحاً بالصيغة المطلوبة حديثاً تجتاز هذا الفحص لدى الاثنين. أما إذا استخدم التوقيع ترميزاً كان مسموحاً وأصبح ممنوعاً، فسترفضه آنا، بينما قد يظل بافل يقبله. نفترض هنا أن الدفعة تستوفي بقية القواعد. هذا هو جوهر Soft Fork: القواعد الجديدة تمنع حالات إضافية من دون أن تسمح بشيء كانت القواعد القديمة تمنعه. ما دام المعدّنون ينتجون كتلاً تستوفي القواعد الأشد، يستطيع الاثنان متابعة السلسلة. لكن بافل لا يفحص الشرط المضاف بنفسه. لذلك يتيح Soft Fork تغيير Bitcoin من دون تحديث جميع العقد في اللحظة نفسها. وهذا لا يجعل فحوص البرنامج القديم مساوية لفحوص الجديد، ولا ينشئ بحد ذاته عملة ثانية. [1] [6]

Full Node هو حاسوب يتحقق مستقلاً من قواعد Bitcoin. وعند الاختيار بين فروع صالحة، يقارن العمل المتراكم المثبت بالتعدين، لا أصوات المؤيدين. تستطيع العقدة الكاملة القديمة متابعة السلسلة لأن المعدّنين المحدّثين ينتجون عادة كتلًا تقبلها، لكنها لا تفحص الشرط المضاف. قد تقبل فرعاً ذا عمل أكبر يخالف القاعدة الجديدة فيما ترفضه العقد المحدّثة. من يحتاج الضمان الجديد يجب أن يحدّث أداة التحقق لديه. استقبال دفعة وفهم العنوان والتحقق الكامل من الإجماع قدرات مختلفة. [1] [12]

BIP هو مقترح تقني مرقّم. نشره لا يغيّر الشبكة وحده؛ فلا بد من تطوير البرنامج وفحصه، ثم يقرر المستخدمون إن كانوا سيشغّلونه. Mainnet هي شبكة Bitcoin الرئيسية التي تُنقل عليها بيتكوينات حقيقية. ويحدد التفعيل متى تبدأ العقد المحدّثة بطلب الالتزام بالقاعدة الجديدة. لذلك يختلف وجود الكود في البرنامج عن استخدامه للتحقق من الكتل. في إجراءات التفعيل الموصوفة هنا، تعني مرحلة lock-in أن شرط التفعيل اللاحق قد تحقق، لكن القاعدة نفسها قد لا تكون مطبّقة بعد. ولا تفحصها العقدة إلا عند بلوغ حالة ACTIVE. وتحسب الحالة من الكتل السابقة في فرعها. فإذا غيّرت إعادة تنظيم السلسلة هذا التاريخ قرب حد التفعيل، فقد تتغير النتيجة المحسوبة أيضاً. لهذا قد يقبل برنامجان بمعلمات تفعيل مختلفة كتلاً مختلفة في اللحظة نفسها. [2] [15]

يبني المعدّن كتلته فوق كتلة سابقة تسمى أيضاً الكتلة الأم. إن لم يتحقق منها فقد يهدر جهده على فرع ترفضه العقد الأخرى. في يوليو 2015 أشار بعض المعدّنين إلى BIP66 لكنهم لم يتحققوا جيداً من الكتلة الأم. بنوا فوق كتلة غير صالحة فأنشؤوا فرعاً غير صالح من ست كتل في 4 يوليو وآخر أقصر في اليوم التالي. رفضتها العقد المحدّثة. رقم الإصدار ادعاء من المعدّن، لا دليل على أنه تحقق مستقلاً من القالب والأصل والمعاملات. [6] [14]

لمعرفة القواعد التي تطبّقها عقدتك فعلاً، ابدأ بإصدار البرنامج والمعلومات التي تعيدها العقدة نفسها. بحسب الإصدار، يقدّم getdeploymentinfo وgetblockchaininfo معلومات عن التغييرات المنشورة وعن السلسلة. وتساعد هذه المعلومات، مع وثائق الإصدار وارتفاع التفعيل والسجلات، في تمييز القاعدة الجاهزة من القاعدة المطبّقة بالفعل. أما مستكشف الكتل على الويب فيعرض منظور خدمة أخرى، ولا يثبت ما يفحصه حاسوبك. يقيس Hashrate القدرة الحسابية للتعدين، لكنه لا يمنح المعدّنين حق تجاوز قواعد عقدتك. في حالة ACTIVE ترفض العقدة المحدّثة كتلة تخالف الشرط الجديد، حتى إن دعمتها أغلبية القدرة الحسابية. ويتوقف استمرار انقسام السلسلة أيضاً على العمل المتراكم في كل فرع وعلى استخدام الناس له اقتصادياً. إزالة قيد مطبّق ببساطة ستسمح مجدداً بكتل غير صالحة حالياً، ولذلك ستكون Hard Fork. قبل التفعيل يمكن تغيير المعلمات بإصدار برمجي منسق، لكن هذا التغيير أيضاً لا يثبّت نفسه تلقائياً على عقد الآخرين. [1] [15] [16]

يرمز V(old) إلى كل الكتل المقبولة بالقواعد القديمة، ويرمز V(new) إلى الكتل المقبولة بالقواعد الجديدة. يكون التغيير Soft Fork عندما تكون V(new) مجموعة فرعية من V(old): ترفض العقدة المحدّثة حالات إضافية، لكن كل كتلة تستوفي القواعد الجديدة تجتاز الفحوص القديمة أيضاً. يصف الاسم علاقة الصلاحية بين القواعد، ولا يعني أن التغيير صغير أو آمن أو محل اتفاق. رفع حد تراه العقدة القديمة، أو السماح بإنفاق كان ممنوعاً، يوسّع مجموعة الحالات المقبولة ويتطلب عادة Hard Fork. [1] [17]

قد تضيف القواعد الأشد وظيفة جديدة أيضاً. فقد حدّد BIP66 بدقة صيغة DER لترميز بيانات التوقيع. وأضاف BIP65 وBIP112 شروطاً زمنية للإنفاق إلى أوامر NOP مختارة لم تكن تفرض شروطاً من قبل. وأدخل SegWit برامج witness وبيانات تحقق تسمى witness، منها التوقيعات. ثم استخدم Taproot الإصدار المحجوز 1. لا تفحص العقد القديمة الشروط الجديدة المعنية؛ لذا يصف anyone-can-spend منظورها المحدود، لا وسيلة لتجاوز العقد المحدّثة وإنفاق أموال الغير. كذلك يربط SegWit بيانات witness بالكتلة تشفيرياً عبر witness commitment. يُسجَّل هذا الربط في معاملة coinbase، أول معاملة تتضمن مكافأة المعدّن، ويحافظ على التوافق مع قواعد الكتلة الأساسية القديمة. [6] [5] [7] [8] [12]

البت قيمة تساوي 0 أو 1. ويمكن لبتات منفردة في nVersion، وهو حقل الإصدار في ترويسة الكتلة، أن تشير إلى جاهزية المعدّن. يخصص BIP9 لكل نشر اسماً وبتاً معيناً ووقت بداية ومهلة نهائية. تقيّم آلية mainnet الأصلية فترات من 2016 كتلة. إذا أشارت 1916 كتلة على الأقل أثناء STARTED، أي 95 %، تدخل الفترة التالية حالة LOCKED_IN. وبعد فترة انتظار أخرى تأتي ACTIVE. إذا لم يتحقق الشرط قبل انتهاء المهلة، فقد تنتهي العملية بحالة FAILED. أما الحالة الأولية قبل البداية فتسمى DEFINED. تحسب كل عقدة هذا التسلسل من الكتل السابقة. لذلك لا يحدد nVersion الخاص بالكتلة نفسها ما إذا كانت القاعدة الجديدة تنطبق عليها. تساعد الإشارات على تنسيق الانتقال، وليست اقتراعاً على صلاحية كل كتلة. وبعد بلوغ lock-in لا تغيّر الإشارات اللاحقة نتيجة هذه الآلية. [2]

تتيح Versionbits للمعدّنين إظهار جاهزيتهم، ولا تمنحهم حق تعديل قواعد العقد الأخرى. يستخدم BIP8 ارتفاعات الكتل بدل الحدود الزمنية. إذا كانت lockinontimeout تساوي true ولم يصل النشر بعد إلى lock-in، فقد تنتقل الفترة الأخيرة إلى MUST_SIGNAL مع إلزامية الإشارة. ألزم BIP148 العقد المشاركة برفض الكتل التي لا تشير إلى SegWit؛ واستخدم BIP91 عتبة أقل لإشارات المعدّنين لتنسيق الانتقال. إذا اختلف تطبيق القواعد وhashrate والقبول الاقتصادي، فقد تنقسم السلسلة. لذلك ينطوي اختيار آلية التفعيل على مفاضلات أمنية. [11] [9] [10] [17]

يسمح P2SH (BIP16) بإرسال الأموال إلى بصمة سكربت، أي برنامج يحدد شروط إنفاقها لاحقاً. وعند إدخاله في 2012 ساعدت الإشارات في معاملات coinbase على تقييم جاهزية المعدّنين. لكن الفحوص الجديدة نفسها بدأت تنطبق عند حد محدد للطوابع الزمنية للكتل؛ فالإشارة لا تحل محل التحقق. Coinbase هي أول معاملة في الكتلة وتتضمن مكافأة المعدّن. استخدمت التغييرات اللاحقة إصدار الكتلة وعتبات الإشارة. ألزم BIP34 بتسجيل ارتفاع الكتلة، أي موقعها في السلسلة، في coinbase. وشدّد BIP66 صيغة توقيعات DER، بينما أدخل BIP65 أمر CHECKLOCKTIMEVERIFY للتحقق من أبكر وقت أو ارتفاع يسمح بالإنفاق. وكان رفع رقم الإصدار تباعاً يصعّب إدخال تغييرات مستقلة بالتوازي، لذلك أضاف BIP9 بتات منفصلة. في 2016 فُعّلت BIP68 وBIP112 وBIP113 معاً عند الارتفاع 419328، لكنها تتناول شروطاً زمنية مختلفة. يضيف BIP68 انتظاراً نسبياً يبدأ من تأكيد المخرج المراد إنفاقه. ويتيح BIP112 فرض هذا الانتظار داخل السكربت بواسطة CHECKSEQUENCEVERIFY، أو CSV. أما BIP113 فيغيّر المرجع الزمني للقفل المطلق للمعاملة: يستخدم Median Time Past، أي وسيط الطوابع الزمنية للكتل الـ11 السابقة، بدلاً من طابع الكتلة الجاري تقييمها. لذلك لا يعني التفعيل المشترك أن المقترحات الثلاثة تضيف القفل النسبي نفسه. [3] [4] [5] [6] [7] [18] [19] [20]

فُعّل SegWit عند الارتفاع 481824 في أغسطس 2017. وفصل بيانات التحقق witness، ومنها التوقيعات، عن الجزء المستخدم لحساب معرّف المعاملة txid. لماذا يهم ذلك؟ في الترميز الأقدم كان بالإمكان تغيير طريقة تمثيل التوقيع، ومن ثم معرّف المعاملة، من دون تغيير المستلم أو المبلغ المدفوع. تسمى هذه الإمكانية malleability، أي قابلية المعاملة لهذا النوع من التعديل. تغيير بيانات witness وحدها لا يغيّر txid، لكن هذا الأسلوب لا يصلح المدخلات التي تواصل استخدام الصيغة القديمة. ترى العقدة القديمة المعاملة بلا witness وتتعامل مع برنامج witness v0 بوصفه anyone-can-spend. أما العقدة المحدّثة فتفحص أيضاً witness وبصمة التوقيع، أي بصمة البيانات المراد توقيعها. يربط witness commitment المسجل في مخرج coinbase بيانات witness بالكتلة تشفيرياً، بحيث يكشف التحقق الكامل تغييرها أو حذفها. وسمح weight، أي وزن البيانات عند احتساب سعة الكتلة، بزيادة السعة الفعلية، بينما بقيت الكتلة الأساسية التي تراها العقد القديمة ضمن حد الميغابايت الأصلي. [8]

يسمح key-path بالإنفاق بتوقيع يناسب مفتاح المخرج، بينما يتطلب script-path استيفاء شروط سكربت يُكشف عنه. Schnorr أسلوب توقيع وTapscript لغة هذه السكربتات. تحدّد BIP341 وBIP342 الإنفاق عبر key-path وscript-path باستخدام توقيعات Schnorr وTapscript لمخرجات SegWit الأصلية ذات برنامج witness من الإصدار 1 بطول 32 بايت. تراها العقد القديمة anyone-can-spend، فتحافظ على التوافق لا التحقق الكامل. استخدم Speedy Trial ‏BIP9 معدلاً وعتبة 1815/2016 (90%) وارتفاعاً أدنى 709632؛ وفُعّل Taproot هناك في 14 نوفمبر 2021. يجب تقييم القواعد وآلية تفعيلها منفصلتين. [12] [13] [16]