الأخبار

هارد فورك مقابل سوفت فورك

يبدو أن فوركس ، أو التهديد منها ، سمة ثابتة في مشهد العملات المشفرة. لكن ما هم؟ لماذا هم صفقة كبيرة؟ وما الفرق بين الشوكة الصلبة والشوكة اللينة؟

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

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

شيء واحد يجب أن تضعه في الاعتبار مع الشوكات هو أن لديهم “تاريخًا مشتركًا”. سجل المعاملات على كل من السلاسل (القديمة والجديدة) مطابق قبل الانقسام.

شوكات صلبة

هناك نوعان رئيسيان من مفترق البرمجة:

  • شوكة صلبة.
  • شوكة ناعمة.

الهارد فورك هو تغيير في بروتوكول blockchain يجعل الإصدارات القديمة غير صالحة. إذا استمرت الإصدارات الأقدم في العمل ، فسينتهي بها الأمر ببروتوكول مختلف وببيانات مختلفة عن الإصدار الأحدث. يمكن أن يؤدي هذا إلى ارتباك كبير وأخطاء محتملة.

مع Bitcoin ، سيكون من الضروري إنشاء هارد فورك لتغيير المعلمات المحددة مثل حجم الكتلة ، وخوارزمية صعوبة التعدين ، وحدود المعلومات الإضافية التي يمكن إضافتها ، وما إلى ذلك. قد يؤدي التغيير في أي من هذه القواعد إلى قبول الكتل من قبل بروتوكول جديد ولكن رفضته الإصدارات القديمة ويمكن أن يؤدي إلى مشاكل خطيرة – وربما حتى فقدان الأموال.

على سبيل المثال ، إذا تمت زيادة حد حجم الكتلة من 1 ميجابايت إلى 4 ميجابايت ، فسيتم قبول كتلة بحجم 2 ميجابايت بواسطة العقد التي تقوم بتشغيل الإصدار الجديد ، ولكن سيتم رفضها بواسطة العقد التي تقوم بتشغيل الإصدار الأقدم.

لنفترض أنه تم التحقق من صحة هذه الكتلة البالغة 2 ميجابايت بواسطة عقدة محدثة وإضافتها إلى blockchain. ماذا لو تم التحقق من صحة الكتلة التالية بواسطة عقدة تقوم بتشغيل إصدار أقدم من البروتوكول؟ سيحاول إضافة كتلته إلى blockchain ، لكنه سيكتشف أن أحدث كتلة غير صالحة. لذلك ، سوف يتجاهل تلك الكتلة ويرفق التحقق الجديد الخاص به بالسابق.

فجأة لديك نوعان من سلاسل الكتل ، أحدهما يحتوي على كلٍّ من كتل الإصدارات الأقدم والأحدث ، والآخر يحتوي على كتل الإصدار الأقدم فقط. تعتمد السلسلة التي تنمو بشكل أسرع على العقد التي يتم التحقق من صحة الكتل التالية ، وقد ينتهي الأمر بكونها انقسامات إضافية. من الممكن أن تنمو السلسلتان (أو أكثر) بالتوازي إلى أجل غير مسمى.

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

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

أو ، انقسام البيتكوين ، وهو ما حدث (مرحبًا ، بيتكوين كاش).

شوكة ناعمة

الشوكة الناعمة هي في الأساس عكس الهارد فورك ، حيث تظل التغييرات التي تم تنفيذها حديثًا متوافقة مع الإصدارات القديمة.

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

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

على سبيل المثال ، لنفترض أن المجتمع قرر تقليل حجم الكتلة إلى 0.5 ميجابايت من الحد النظري الحالي البالغ 4 ميجابايت (مع كتل SegWit.) سترفض عقد الإصدار الجديد الكتل بالحد القديم وستبني على الكتلة السابقة (إذا تم تعدينها) بإصدار محدث من الكود) ، مما قد يتسبب في انقسام مؤقت.

هذه شوكة ناعمة ، وقد حدث بالفعل عدة مرات. في البداية ، لم يكن لدى Bitcoin حد لحجم الكتلة. تم تقديم حد 1 ميغا بايت من خلال شوكة ناعمة لأن القاعدة الجديدة كانت “أكثر صرامة” من القاعدة القديمة.

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

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

للحصول على أمثلة للتغييرات التي قد تتطلب انقسامًا بسيطًا ، راجع قسم “قائمة الرغبات softfork“.

مقالات ذات صلة

اترك تعليقاً

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *

زر الذهاب إلى الأعلى

أنت تستخدم إضافة Adblock

برجاء دعمنا عن طريق تعطيل إضافة Adblock