حرب حجم الكتلة

لنتخيل حاجتين عاديتين. تريد آنا إرسال بيتكوين دون انتظار طويل أو رسوم مرتفعة. ويشغّل بافل عقدة كاملة، أي حاسوبًا يتحقق بنفسه من الكتل والمعاملات. يريد التحقق من أمواله دون معدات باهظة. الحاجتان منطقيتان، لكن زيادة بيانات كل كتلة تعني أيضًا مزيدًا من البيانات التي يجب نقلها وفحصها. كان هذا التوازن في قلب Block Size War. الكتلة مجموعة معاملات تُضاف إلى سجل المدفوعات المشترك في الشبكة. آنا وبافل شخصيتان توضيحيتان. أما النقاش الحقيقي في 2015–2017 فشارك فيه مطورون ومشغلو تعدين ومنصات تداول ومزودو محافظ ومستخدمون. لم يختلفوا على السعة فقط، بل على كيفية إدخال التغيير بأمان. لم يكن لدى Bitcoin مدير يختار أحد المقترحات ويأمر الجميع بالانتقال إليه. [1] [11] [13]

قبل SegWit كانت القواعد تحد حجم الكتلة عند 1 MB، أي 1 000 000 بايت. لم يكن هذا عددًا ثابتًا من المدفوعات، فالمعاملات تشغل أحجامًا مختلفة. تظهر كتلة جديدة كل عشر دقائق تقريبًا في المتوسط. وعندما يتجاوز الطلب المساحة المتاحة، يعطي المعدّنون عادة الأولوية للمعاملات ذات معدل الرسوم الأعلى وتنتظر البقية. أراد مؤيدو الكتل الأكبر إضافة مساحة مباشرة إلى الشبكة الأساسية وإبقاء المدفوعات ميسورة. وخشي المعارضون ارتفاع متطلبات الاتصال والحواسيب وسرعة نشر الكتل. فإذا قلّ عدد القادرين على التحقق بأنفسهم، سيضطر مزيد من المستخدمين إلى الوثوق بخدمات الآخرين. رفع الحد وحده لا يسرّع إنشاء الكتل ولا يضمن رسومًا منخفضة دائمًا؛ فالطلب والاستخدام الفعلي للمساحة مهمان أيضًا. [1] [2] [13]

يستطيع المطور كتابة برنامج جديد، ويستطيع المعدّن إنشاء كتلة وفقه. لكن مشغّل Full Node يختار القواعد التي تتحقق منها عقدته. حتى أغلبية القدرة الحاسوبية لا تستطيع إجبار عقدة لم تتغير على قبول كتلة تخالف قواعدها. تساعد القدرة الحاسوبية في الاختيار بين سلاسل صالحة، ولا تجعل الكتلة غير الصالحة صالحة. لا يعني ذلك أن لكل عقدة صوتًا في اقتراع عالمي، أو أن شخصًا واحدًا يستطيع منع الآخرين من المغادرة. تختار الشركات ما تقبله، والمعدّنون ما يعدّنونه، والمستخدمون ما يمنحونه قيمة. وقد تنتج شبكتان عن قواعد غير متوافقة. لذلك كان الاتفاق التجاري قادرًا على دعم التغيير، لكنه لا يعيد كتابة برامج الجميع وقراراتهم تلقائيًا. [11] [12]

وُثّقت المقترحات في مستندات BIP، اختصارًا لـBitcoin Improvement Proposal. يشرح المستند المقترح كي يتمكن الآخرون من مراجعته ومناقشته. حصوله على رقم لا يعني أن الشبكة اعتمدته. اقترح Gavin Andresen في BIP 101 رفع الحد إلى 8 MB، ثم زيادته وفق جدول محدد. شمل المقترح مضاعفة تقريبية كل عامين وشروطًا للتفعيل. ودعم Mike Hearn مع Andresen برنامج Bitcoin XT البديل الذي يتيح هذا المسار. لكن نشر البرنامج لم يكن مساويًا لتغيير قواعد الشبكة بأكملها. كانت العقد القديمة سترفض كتلة تتجاوز الحد السابق. فهذا Hard Fork، أي تغيير يوسّع مجموعة الكتل المسموح بها ويحتاج مستقبِلوها إلى قواعد مختلفة لقبولها. وبذلك تجاوز النقاش سؤال مقدار المساحة الإضافية: من سينتقل، وكيف يجري تنسيق الانتقال، وماذا يحدث إن اعترض جزء مؤثر من المشاركين؟ [1] [18] [13]

شرح Eric Lombrozo وJohnson Lau وPieter Wuille مسارًا آخر في BIP 141. أعاد SegWit تنظيم بيانات المعاملات وأدخل وزن الكتلة بحد 4 000 000 weight units. يحتوي الجزء المسمى witness خصوصًا على بيانات التحقق من صلاحية الإنفاق. لم تختف هذه البيانات ولم يتوقف فحصها؛ وإنما اختلف احتسابها في الوزن. تعتمد السعة الفعلية على تركيب المعاملات، وليس على مجرد السماح بكتل عادية حجمها أربعة ميغابايت. يحدد الوزن كيفية احتساب البيانات ضمن حد الكتلة: يُحسب بايت البيانات الأساسية بـ4 وحدات، وبايت البيانات الإضافية المرتبطة بـwitness بوحدة 1. لذلك قد تستهلك معاملتان متساويتان في عدد البايتات وزنًا مختلفًا. وتتأثر السعة أيضًا بأنواع المعاملات التي يستخدمها الناس. وفي المعاملات المعنية، منع SegWit أيضًا تغيير معرّف المعاملة عبر تعديل بيانات التوقيع. سهّل ذلك إنشاء قنوات الدفع التي تقوم عليها Lightning Network. وصُمم بوصفه Soft Fork: تظل الكتل الصالحة الجديدة ضمن القواعد القديمة، لكن العقد الأقدم لا تفحص كل القيود الجديدة. تضمّن Bitcoin Core 0.13.1 آلية التفعيل؛ ولم يكن إصدار البرنامج وحده تشغيلًا لـSegWit. [2] [3]

في 23 مايو 2017 نشرت Digital Currency Group اتفاق New York Agreement بين شركات ومعدّنين. جمع دعم SegWit مع وعد بإجراء Hard Fork إلى 2 MB خلال ستة أشهر. عُرفت الخطوة الثانية باسم SegWit2x، وكان مشروع btc1 تطبيقها البرمجي. رآها بعض المشاركين تسوية مقبولة: يحصل كل طرف على جزء مما يريد. لكن آخرين رفضوا التغيير الثاني وطريقة الدفع به. لم يكن دعم الشركة موافقة تلقائية من جميع عملائها. وأوضح Bitcoin Core لاحقًا أن btc1 ليس تحديثًا إلزاميًا لبرنامجه، وأن دعم SegWit لا يعني دعم SegWit2x. عند قراءة أخبار تلك المرحلة، ينبغي التمييز بين تغييرين للقواعد حتى إن جمعهما اتفاق واحد. [6] [7] [11]

اقترح الكاتب ذو الاسم المستعار Shaolin Fry مقترح BIP 148، وهو شكل من UASF، أي Soft Fork يفعّله المستخدمون. بدءًا من 1 أغسطس 2017 وفق Median Time Past، كانت العقد المطبقة له سترفض الكتل التي لا تشير إلى دعم SegWit، ما لم يكن تفعيله قد حُسم أو بدأ بالفعل. ولو اختلف التعدين وقبول الكتل، لأمكن أن تنقسم الشبكة. لم يكن مفتاحًا خاليًا من المخاطر يتحكم فيه كل المستخدمين معًا. Median Time Past هو القيمة الواقعة في المنتصف بعد ترتيب الطوابع الزمنية لآخر 11 كتلة، وليس الوقت على ساعة كل مستخدم. وكانت الإشارة علامة في ترويسة الكتلة تعبّر عن دعم المعدّن لذلك التطبيق، ولا تُفعّل القواعد الجديدة بمفردها. وشرح James Hilliard في BIP 91 تنسيقًا للمعدّنين بعتبة أقل: 269 من أصل 336 كتلة، أي نحو 80%. بعد سريان الآلية، كان المشاركون سيرفضون الكتل التي لا تشير إلى نشر SegWit الأصلي. قلّل تنسيق يوليو خطر الخلاف حول موعد أغسطس، لكنه لم يعنِ أن SegWit نفسه حُسم أو فُعّل في يوليو. فقد ظل يتبع آليته الخاصة في BIP 9. [4] [5] [9] [19]

انفصل Bitcoin Cash في 1 أغسطس 2017. ودعم برنامج Bitcoin ABC كتلًا أكبر لهذا الفرع، بحد افتراضي آنذاك قدره 8 MB. منذ الانفصال، أصبحت للشبكتين قواعد وعملات مختلفة. ولم يكن اشتراكهما في التاريخ السابق يعني إمكان نقل المدفوعات اللاحقة بحرية بين BTC وBCH. لم يكن Bitcoin Cash هو SegWit2x، ولا Bitcoin ABC هو btc1. خلط هذه الأسماء يخلط انفصال أغسطس بخطة أخرى عُلقت لاحقًا. واختلفت أيضًا replay protection، أي الحماية من تكرار المعاملة على السلسلة الأخرى. كان لذلك أثر عملي: ينبغي ألا تؤدي عملية في فرع إلى إنفاق أموال الفرع الآخر دون قصد. كما لم يكن إدخال المفاتيح المشتركة في أي أداة تعد بعملات جديدة أمرًا آمنًا. [8] [15] [11]

دخل SegWit حالة LOCKED_IN عند الكتلة 479 808 في 9 أغسطس 2017. انتهت فترة الحسم وبقيت فترة انتظار واحدة قبل تطبيق القواعد الجديدة. وأصبح نشطًا عند الكتلة 481 824 في 24 أغسطس. وبين الارتفاعين 2 016 كتلة. إذًا، تنسيق BIP 91 في يوليو، وحسم التفعيل في أغسطس، والتفعيل نفسه أحداث مختلفة. بقيت الخطوة الثانية من SegWit2x، المقررة عند الارتفاع 494 784. وفي 8 نوفمبر أعلن المنظمون بقيادة Mike Belshe تعليقها: بحسب بيانهم لم يتحقق اتفاق كافٍ لانتقال سلس. لم يفقد Bitcoin بذلك SegWit النشط، ولم تختف شبكة Bitcoin Cash المستقلة. الذي انتهى هو هذه المحاولة المحددة لترجمة دعم الشركات والمعدّنين إلى زيادة حد Bitcoin. [9] [10] [12] [14] [16] [17]

أظهر الخلاف أن Bitcoin قابل للتغيير، لكن كتابة الشيفرة وجمع توقيعات الشركات والحصول على قبول القواعد مهام مختلفة. ولم يثبت أن المطورين بلا تأثير، أو أن المعدّنين غير مهمين، أو أن كل قرار مستقبلي سينتهي بالطريقة نفسها. فالسعة والتحقق الميسور واتفاق المشاركين لا تُحل بمجرد تغيير اسم التحديث. عند قراءة مقترح جديد، اسأل أولًا ما الذي يغيّره، وأي عقد ستختلف بعده، وكيف سيُفعّل. ثم ميّز بين نص المقترح والبرنامج المنشور والقواعد السارية فعلًا. توثّق مقترحات BIP وشيفرات تلك الفترة الآليات، بينما توثّق تصريحات الأطراف مواقفهم. ولا يمثل تصريح أحد المشاركين بمفرده سردًا محايدًا للتاريخ كله. [1] [6] [11] [12]