المؤلف: شاكرا؛ الترجمة: 0xjs@金财经
تعد عملة البيتكوين أقدم سلسلة من الكتل وأكثرها أمانًا ولامركزية وأعلى قيمة سوقية في العالم. ومع ذلك، فإن معاملاتها المنخفضة في الثانية (TPS) وقدراتها البرمجية المحدودة غالبًا ما تم انتقادها لأنها تجعل من الصعب دعم التطبيقات واسعة النطاق، مما يعيق بشدة تطوير نظام البيتكوين البيئي. باعتبارك منشئ نظام Bitcoin البيئي، ستقودك هذه المقالة إلى فهم حلول توسيع نطاق Bitcoin في الماضي والحاضر والمستقبل.
هذه المقالة هي الأولى في سلسلة من المقالات حول قابلية التوسع في Bitcoin، والتي تقدم بشكل أساسي حلول التوسع الأصلية التي تم تنفيذها تاريخيًا على شبكة Bitcoin الرئيسية. ستناقش المقالة التالية حلول التوسع خارج السلسلة ذات قابلية التوسع الأعلى. ابقوا متابعين.
زيادة الحد الأقصى لحجم الكتلة
في عام 2010، قدم ساتوشي ناكاموتو حدًا لحجم الكتلة يبلغ 1 ميجابايت في عملة البيتكوين الأساسية. وظل هذا القيد الواضح دون تغيير لأكثر من عشر سنوات.
ومن المثير للاهتمام، ساتوشي ناكاموتو لم يشرح علنًا سبب اقتراحه للحد الأقصى لحجم الكتلة، وكان هذا الحد "مخفيًا" في العلاقات العامة لدمج التعليمات البرمجية ولم يتم شرحه بالتفصيل. بعد سنوات قليلة من مغادرة ساتوشي ناكاموتو، أصبح المجتمع منقسمًا بشدة حول مسألة حدود حجم الكتلة، وأثارت الحاجة إلى كتل أكبر نقاشًا واسع النطاق.
كلما كانت الكتلة أكبر، زادت المعاملات التي يمكنها استيعابها. على افتراض أن وقت الإجماع لم يتغير، كلما كانت الكتلة أكبر، كلما ارتفع TPS.
ما سبب أهمية TPS؟ لأنه في ظل حد الكتلة البالغ 1 ميجابايت ونطاق المعاملات في ذلك الوقت، كان عدد المعاملات التي يمكن إكمالها في الثانية هو 3-7 فقط، وهو ما كان بعيدًا عن أن يكون كافيًا للتطبيقات واسعة النطاق ولم يتمكن من تحقيق "نظير إلى-" الخاص بالبيتكوين. نظام النقد الإلكتروني النظير ""الرؤية.
ومع ذلك، فإن الكتل الأكبر حجمًا تسبب أيضًا درجات متفاوتة من المشكلات.
أولاً وقبل كل شيء، تتطلب الكتل الأكبر حجمًا متطلبات أعلى للأجهزة مثل التخزين والحوسبة وعرض النطاق الترددي، مما يؤدي إلى زيادة تكاليف التشغيل للعقد الكاملة. تتوسع بيانات المعاملات التاريخية للبيتكوين بسرعة، مما يتطلب عقدًا كاملة جديدة لقضاء المزيد من الوقت في المزامنة مع الشبكة. تقلل هذه المتطلبات من رغبة المستخدمين في تشغيل العقد الكاملة، وبالتالي تقليل درجة اللامركزية.
ثانيًا، كلما كانت الكتلة أكبر، زاد وقت المزامنة بين العقد، وزادت احتمالية الكتل اليتيمة، مما يؤدي إلى إعادة تنظيم الكتلة بشكل متكرر، وزيادة خطر الشوكات، وتقليل الأمان بشكل كبير.
أطلق Vitalik على هذه المشكلة لاحقًا اسم المثلث المستحيل لـ blockchain، أي أن blockchain لا يمكنه تحقيق اللامركزية وقابلية التوسع والأمان في نفس الوقت. توفر الكتل الأكبر حجمًا قابلية أكبر للتوسع، ولكن على حساب قدر أقل من اللامركزية والأمن.
أهم شيء هو أن تعديل حد حجم الكتلة يتطلب شوكة صلبة، الأمر الذي يتطلب ترقية جميع العقد في الشبكة بأكملها في نفس الوقت، وإلا فسيؤدي ذلك إلى تقسيم الشبكة. وهذا ليس خيارًا جيدًا للبيتكوين، التي تعتمد على الإجماع اللامركزي. تحت تأثير ساتوشي ناكاموتو، يبدو أن تجنب الهارد فورك أصبح مبدأً فعليًا بالنسبة للبيتكوين.
ولسوء الحظ، حدث الانقسام. على الرغم من عدم وجود إجماع داخل المجتمع، قام بعض عمال المناجم والمطورين بتغيير الحد الأقصى لحجم الكتلة في العميل، مما أدى في النهاية إلى شوكة الشبكة. في عام 2016، اعتمد Bitcoin Classic BIP 109، الذي أدى إلى رفع الحد الأقصى لحجم الكتلة إلى 2 ميجابايت؛ وفي عام 2016، اعتمد عميل Bitcoin XT BIP 101، مما أدى إلى زيادة حجم الكتلة إلى 8 ميجابايت. ومع ذلك، فإن الغالبية العظمى من القائمين بالتعدين والمستخدمين ما زالوا يستخدمون ما نعرفه الآن باسم شبكة البيتكوين الرئيسية.
فشلت الجهود المبذولة لزيادة حجم الكتلة بشكل صريح من خلال الانقسام الكلي.
SegWit
إذا كانت عملية الانقسام الكلي غير مقبولة، فهل يمكن أن تكون عملية الانقسام الشامل هي الحل؟ SegWit هو أحد هذه الأساليب.
الشاهد هو بيانات اعتماد تفتح UTXO لفترة طويلة، تم وضع الشاهد في حقل البرنامج النصي للإدخال الخاص بـ UTXO لإكمال المعاملة. ومع ذلك، فإن هذا النهج ينطوي على مشاكل محتملة مثل التبعية الدائرية، وقابلية تطويع معاملات الطرف الثالث، وقابلية تطويع معاملات الطرف الثاني.
في وقت مبكر من عام 2011 لاحظ المطورون هذه المشكلة واقترحوا حل الشاهد المنفصل (SegWit)، الذي يفصل الشهود عن بيانات المعاملات الأخرى. ومع ذلك، فإن اقتراح الانقسام الكلي في ذلك الوقت لم يحظ بالدعم، ولم يتم تحقيق الاندماج أخيرًا إلا بعد اقتراح انقسام SegWit الناعم في عام 2015.
كيف يحقق SegWit التوافق مع الإصدارات السابقة من خلال الشوكات الناعمة؟ يتضمن هذا بشكل أساسي الجانبين التاليين:
يمكن لعقد الإصدار الجديد التعرف على الكتل والمعاملات التي تم إنشاؤها بواسطة عقد الإصدار القديم وقبولها.
على الرغم من أن عقد الإصدار القديم لا يمكنها التعرف على القواعد والميزات الجديدة التي يقدمها الإصدار الجديد، إلا أنها لا تزال تعتبر الكتل التي أنشأها الإصدار الجديد صالحة.
يسمح شوكة SegWit الناعمة للمعاملات الجديدة باستخدام نصوص الإدخال الفارغة وإضافة حقل شاهد إلى بنية الكتلة لتخزين الشهود. نظرًا لأن Bitcoin Core قبل الترقية يدعم نصوص الإدخال الفارغة، فإن عقد الإصدار القديم لن ترفض الكتل التي تم إنشاؤها بواسطة الإصدار الجديد. بالإضافة إلى ذلك، باستخدام حقل الإصدار، لا يزال من الممكن استخدام أنواع المعاملات الأقدم، وستتعامل معها العقد بشكل مختلف اعتمادًا على الإصدار.
الامتدادات في SegWit It يتم تنفيذه على شكل أوزان، ويبلغ وزن البايت الشاهد 1 ووزن بايتات البيانات الأخرى 4، مما يحد من الحد الأقصى لوزن كل كتلة إلى 4 ملايين. لماذا يتم تخصيص أوزان مختلفة لأنواع مختلفة من البيانات؟ الفكرة المنطقية هي أن بيانات الشاهد تلعب دورًا تحققًا فقط عند استخدامها ولا تحتاج إلى تخزينها في المخزن لفترة طويلة، وبالتالي فإن التكلفة منخفضة نسبيًا والوزن منخفض أيضًا.
هذا هو في الواقع تم زيادة الحد الأقصى لحجم الكتلة بشكل مقنع، وتم رفع الحد الأعلى النظري لحجم الكتلة إلى 4 ميجابايت (بسبب بيانات الشاهد بالكامل، في المتوسط، يمكن أن يصل حجم الكتلة إلى حوالي 2 ميجابايت). انطلاقًا من بنية الكتلة القديمة، لا يزال هذا ملتزمًا بالحد الأصلي لساتوشي ناكاموتو والذي لا يزيد عن 1 ميجابايت لكل كتلة.
Taproot
باستخدام رموز تشغيل Bitcoin مثل OP_IF، يمكننا وضع شروط معقدة لنصوص إنفاق Bitcoin، مثل أقفال الوقت والتوقيعات المتعددة وما إلى ذلك. ومع ذلك، غالبًا ما تتطلب ظروف الإنفاق المعقدة مدخلات وتوقيعات متعددة للتحقق، وبالتالي زيادة تحميل الكتلة وتقليل سرعة المعاملة، مع الكشف عن جميع شروط الدفع، مما يؤدي إلى تسرب الخصوصية.
يستخدم Taproot MAST لـ لتحسين عملة البيتكوين، يستخدم المستخدمون Merkle Trie للتعبير عن شروط الإنفاق. تمثل كل عقدة طرفية برنامجًا نصيًا للإنفاق أثناء عملية الإنفاق، يجب توفير البرنامج النصي الفعلي الذي تم تنفيذه ومسار Merkle المقابل دون الكشف عن شروط أخرى. وهذا يقلل من استهلاك مساحة الكتلة ويحسن الخصوصية.
تقدم ترقية Taproot أيضًا توقيعات Schnorr، وهي متجانسة بشكل إضافي، مما يسمح بتجميع التوقيع والتحقق من الدُفعات، وبالتالي زيادة إجمالي المعاملات في الثانية (TPS). تعمل ميزة التوقيع الإجمالية لتوقيعات شنور على تبسيط منطق التحقق من المعاملات متعددة التوقيع إلى حد كبير. في السابق، كانت توقيعات ECDSA تتطلب إرسال توقيعات متعددة على السلسلة لمطابقة البرنامج النصي، في حين تتطلب توقيعات Schnorr فقط إرسال توقيع مجمع واحد خارج السلسلة على السلسلة، مما يقلل من استخدام المساحة على السلسلة للمدفوعات متعددة التوقيع. .
من خلال الجمع بين توقيعات شنور وMAST واستخدام مفهوم الدفع مقابل العقد (P2C)، يتم إرسال رمز العقد المعقد من خلال جذر MAST للتكيف وإنشاء معيار يدعم مفتاح Bitcoin العام لمدفوعات توقيع شنور الفردية.
من المثير للاهتمام أنه نظرًا لأن التوقيعات الفردية والتوقيعات المتعددة لتوقيعات شنور تبدو متشابهة على السلسلة، فلا يمكن تمييز منطق النصوص المعقدة والتوقيعات المتعددة والتوقيعات الفردية على السلسلة، مما يزيد من تعزيز الخصوصية.
< /p>
الاستنتاج
تعكس حلول قابلية التوسع الخاصة بالبيتكوين جهودها لتحسين الأداء مع الحفاظ على اللامركزية والأمن.
في البداية، تم النظر في زيادة حجم الكتلة لحل مشكلة انخفاض معدل المعاملات بشكل مباشر، ولكنها تسببت في مشاكل تتعلق بتكاليف العقد وشوكات الشبكة، مما يشكل تحديات لإجماع المجتمع.
يمثل تقديم SegWit تقدمًا كبيرًا، حيث يعمل على تحسين سعة الكتلة من خلال الشوكات الناعمة، مما يضمن التوافق مع الإصدارات السابقة وتجنب الشوكات الصلبة المسببة للخلاف.
وبعد ذلك، قامت Taproot بتحسين قابلية التوسع والخصوصية من خلال توقيعات MAST وSchnorr، مما أدى إلى تقليل مساحة المعاملات وتحسين كفاءة التحقق. والأهم من ذلك، أن Taproot يمكنه تنفيذ برمجة نصية معقدة على Bitcoin، مما يمهد الطريق لمحاولات التوسع المستقبلية.
تسلط هذه التطورات الضوء على تحرك Bitcoin الحذر والمبتكر نحو شبكة أكثر قوة وقابلية للتوسع، وهو أمر بالغ الأهمية لمستقبلها كنظام مدفوعات عالمي.
ومع ذلك، فإن تأثير خطط التوسع هذه ليس كافيًا لتحقيق رؤية "نظام النقد الإلكتروني من نظير إلى نظير". ص>