قابلية التوسع في البيتكوين: تحليل حلول الطبقة الثانية والمشاريع ذات الصلة

المؤلف: Chakra; الترجمة: 0xjs@金财经

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

السلاسل الجانبية

يعود مفهوم السلاسل الجانبية إلى عام 2014، عندما قدمت Blockstream "ابتكار Blockchain مع السلاسل الجانبية المرتبطة". إنه يمثل طريقة قياس أساسية نسبيًا.

كيف تعمل السلسلة الجانبية؟

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

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

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

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

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

المشكلات والأساليب

تتضمن الانتقادات الرئيسية للسلاسل الجانبية ما يلي:

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

2. لا يمكن للسلاسل الجانبية أن ترث أمان السلسلة الرئيسية: نظرًا لأن السلاسل الجانبية تعمل بشكل مستقل تمامًا عن الشبكة الرئيسية، فلا يمكنها أن ترث أمان الشبكة الرئيسية، مما قد يؤدي إلى إعادة تنظيم الكتلة الضارة.

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

دراسة حالة

السائل

أحد الأشكال المبكرة للسلاسل الجانبية هي السلاسل الجانبية الموحدة، والتي تعتمد على سلسلة محددة مسبقًا يعمل كيان المجموعة كمدقق وهو مسؤول عن حماية الأصول على الشبكة الرئيسية وإنشاء الكتل على السلسلة الجانبية.

يعد Liquid مثالًا كلاسيكيًا على سلسلة جانبية اتحادية، حيث يعمل 15 طرفًا كمدققين. إدارة المفتاح الخاص ليست عامة ويتطلب التحقق 11 من 15 توقيعًا. يتم أيضًا الحفاظ على إنتاج الكتل على Liquid Sidechain بواسطة هؤلاء المشاركين الخمسة عشر. يؤدي العدد الأصغر من العقد في هذا الاتحاد إلى زيادة المعاملات في الثانية (TPS)، وبالتالي تحقيق أهداف قابلية التوسع، ومجال التطبيق الرئيسي هو DeFi.

ومع ذلك، فإن نموذج السلسلة الجانبية الموحدة ينطوي على مخاطر أمنية مركزية كبيرة.

Rootstock (RSK)

تتم إدارة RSK أيضًا بواسطة 15 عقدة مسؤولة عن استضافة أموال الشبكة الرئيسية ويتطلب التحقق 8 توقيعات فقط. على عكس Liquid، تتم إدارة مفاتيح RSK متعددة التوقيع من خلال وحدة أمان الأجهزة (HSM) ويتم توقيع تعليمات الخطاف بناءً على إجماع إثبات العمل (PoW)، مما يمنع المدققين الذين لديهم وصول رئيسي من التعامل مباشرة مع أموال الضمان.

من حيث إجماع السلسلة الجانبية، تتبنى RSK التعدين المدمج وتستخدم قوة حوسبة الشبكة الرئيسية لضمان أمان معاملات السلسلة الجانبية. عندما يتم استخدام جزء كبير من قوة حوسبة الشبكة الرئيسية للتعدين المدمج، يمكن أن يمنع بشكل فعال هجوم الزهرة المزدوجة. لقد تحسنت RSK على أساس التعدين المدمج، من خلال الوعي بالشوكة، وتقوم بإجراء تدخل إجماعي خارج السلسلة على سلوك الشوكة، وبالتالي ضمان أمان السلاسل الجانبية في ظل قوة حوسبة منخفضة وتقليل احتمالية هجمات الإنفاق المزدوج.

ومع ذلك، فإن التعدين المدمج يغير آلية الحوافز للقائمين بالتعدين، ويزيد من مخاطر القيمة القابلة للاستخراج (MEV)، وقد يقوض استقرار النظام. وبمرور الوقت، قد يؤدي التعدين المدمج إلى زيادة مركزية التعدين.

الأكوام

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

تقدم sBTC نموذجًا جديدًا للرموز والحوافز باستخدام جسر التوقيع الذي يسمح بما يصل إلى 150 من أدوات التحقق من صحة الشبكة الرئيسية. يحتاج المدققون إلى مشاركة رموز STX للوصول إلى الودائع والسحوبات المعتمدة. يعتمد أمان جسر التوقيع إلى حد كبير على قيمة الأصول المرهونة، مما يشكل خطرًا على الأمن عبر سلسلة BTC خلال فترات التقلبات الكبيرة في أسعار الأصول المرهونة.

تتم حاليًا مناقشة مقترحات السلسلة الجانبية الأخرى على نطاق واسع في المجتمع.

Drivechain

وأبرزها هو اقتراح Drivechain الذي قدمه Paul Sztorc في عام 2015، والذي خصص التقنيات الرئيسية لـ BIP 300 (آلية مربوطة). وBIP 301 (التعدين المدمج الأعمى). يحدد BIP 300 منطق إضافة سلاسل جانبية جديدة، على غرار تنشيط سلاسل جانبية جديدة من خلال إشارات التعدين (مثل الشوكات الناعمة). يسمح BIP 301 للقائمين بتعدين Bitcoin بأن يصبحوا منتجين للكتل على السلاسل الجانبية دون التحقق من التفاصيل المحددة للمعاملات.

يتحمل القائمون بتعدين البيتكوين أيضًا مسؤولية الموافقة على معاملات السحب. يبدأون اقتراح السحب عن طريق إنشاء مخرجات OP_RETURN في معاملة قاعدة العملات الخاصة بالكتلة التي قاموا بتعدينها. يمكن لعمال المناجم الآخرين بعد ذلك التصويت على الاقتراح من خلال دعمه أو معارضته في كل كتلة يقومون بتعدينها. بمجرد تجاوز معاملة السحب العتبة (13,150 كتلة)، يتم تنفيذها وتأكيدها على سلسلة البيتكوين الرئيسية.

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

Spacechain

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

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

بشكل عام، تهدف Spacechain إلى تحقيق سلسلة جانبية لا مركزية ومقاومة للرقابة مثل Bitcoin، مع زيادة قابلية البرمجة من خلال ميزة المزاد الشامل.

Softchain

Softchain هو مقترح آخر لسلسلة جانبية (2wp) لربط سلسلة جانبية من قبل Ruben Somsen يستخدم آلية إجماع PoW FP لتأمين السلسلة الجانبية. في ظل الظروف العادية، تحتاج عقد البيتكوين الكاملة فقط إلى تنزيل رأس كتلة Softchain للتحقق من إثبات العمل. في حالة حدوث تفرع، يقومون بتنزيل الكتلة اليتيمة والتزام مجموعة UTXO المقابل للتحقق من صحة الكتلة.

بالنسبة لآلية 2wp، عند تحويل الربط، سيتم إنشاء معاملة إيداع على السلسلة الرئيسية، وستشير Softchain إلى معاملة السلسلة الرئيسية هذه للحصول على الأموال عند تحويل الربط؛ ، سيتم إنشاء معاملة إيداع على معاملة سحب Softchain، وستشير السلسلة الرئيسية إلى هذه المعاملة لاسترداد BTC بعد فترة تحدي طويلة. تتطلب آليات ربط النقل والتحويل المحددة دعم الشوكة الناعمة، لذلك يسمى الاقتراح Softchain.

يضيف اقتراح Softchain تكاليف تحقق إضافية إلى العقد الكاملة لشبكة Bitcoin الرئيسية، وقد يؤثر انقسام الإجماع داخل Softchain على إجماع الشبكة الرئيسية ويشكل ناقل هجوم محتمل للبيتكوين.

الشبكة المسرّعة

تم إصدار الورقة البيضاء للشبكة المسرّعة في عام 2015 وتم إطلاقها رسميًا في عام 2018. وباعتبارها بروتوكول دفع من نقطة إلى نقطة من الطبقة الثانية على شبكة البيتكوين، فإنها تهدف إلى إن نقل عدد كبير من المعاملات الصغيرة عالية التردد إلى المعالجة خارج السلسلة يعتبر دائمًا الحل التوسعي الواعد لشبكة Bitcoin.

الوحدة الأساسية

يعتمد تنفيذ الشبكة المسرّعة على عدة وحدات مهمة داخل Bitcoin، والتي تضمن معًا أمان معاملات الشبكة.

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

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

ومع ذلك، يمكن أن يتسبب 2 من 2 multisig في حدوث مشكلات حيوية، وإذا لم يتعاون أحد الطرفين، فلن يتمكن الطرف الآخر من تحويل أي أموال من عنوان multisig، مما يؤدي إلى فقدان الأموال الأصلية. يمكن للأقفال الزمنية أن تحل مشكلة النشاط؛ من خلال التوقيع المسبق على عقد مع القفل الزمني لإعادة الأموال، يمكنك التأكد من أنه حتى لو كان أحد الطرفين غير نشط، فلا يزال بإمكان الطرف الآخر استرداد الأموال الأولية.

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

عملية التشغيل

قناة ثنائية الاتجاه

لاستخدام الشبكة المسرّعة لإجراء المعاملات، يحتاج كلا الطرفين أولاً إلى فتح قناة ثنائية الاتجاه -قناة الدفع على البيتكوين . يمكنهم إجراء عدد غير محدود من المعاملات خارج السلسلة، وبعد إكمال جميع المعاملات، يرسلون أحدث حالة إلى Bitcoin blockchain لتسوية وإغلاق قناة الدفع.

على وجه التحديد، يتضمن تنفيذ قناة الدفع الخطوات الأساسية التالية:

1. أنشئ عنوانًا متعدد التوقيعات. يحتاج كلا الطرفين أولاً إلى إنشاء عنوان 2 من 2 متعدد التوقيع كقفل صندوق القناة. يحتفظ كل طرف بالمفتاح الخاص المستخدم للتوقيع ويوفر المفتاح العام الخاص به.

2. تهيئة القناة. يقوم كلا الطرفين ببث معاملة على السلسلة، مما يؤدي إلى قفل مبلغ معين من البيتكوين في العنوان متعدد التوقيع باعتباره الأموال الأولية للقناة. تُعرف هذه المعاملة بالمعاملة "الارتساء" للقناة.

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

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

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

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

شبكة الدفع

باستخدام HTLC (عقد قفل وقت التجزئة)، يمكن ربط قنوات الدفع معًا لتكوين شبكة تدعم التوجيه متعدد القفزات. يستخدم HTLC قفل التجزئة كشرط مباشر ودفع التوقيع المقفل بالوقت كشرط احتياطي، مما يسمح للمستخدمين بالتفاعل بناءً على الصور المسبقة المجزأة قبل انتهاء قفل الوقت.

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

المشكلات الحالية

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

1. حد سعة القناة: سعة قناة الدفع في الشبكة المسرّعة محدودة بالقفل الأولي لا يمكن للأموال أن تدعم المدفوعات التي تتجاوز سعة القناة. وقد يحد هذا من حالات استخدام معينة، مثل تداول السلع.

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

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

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

RGB

المفهوم الأصلي لبروتوكول RGB مستوحى من أفكار بيتر تود الخاصة بالتحقق من جانب العميل والختم لمرة واحدة. تم اقتراحه من قبل جياكومو زوكو في عام 2016 كبروتوكول طبقة ثانية قابل للتطوير ويحافظ على الخصوصية للبيتكوين.

المفاهيم الأساسية

التحقق من العميل

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

الختم لمرة واحدة

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

التزامات التشفير

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

سير العمل

يستفيد RGB من إجماع Bitcoin لضمان أمان الإنفاق المزدوج ومقاومة الرقابة، بينما يتم تفويض جميع مهام التحقق من انتقال الحالة إلى السلسلة، ويتم تنفيذها فقط من قبل العميل الذي يتلقى الدفع.

بالنسبة لمصدري أصول RGB، يتضمن إنشاء عقد RGB بدء معاملة يتم فيها تخزين الالتزام بمعلومات محددة في برنامج نصي OP_RETURN ضمن شرط معاملة Taproot.

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

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

المزايا والعيوب

التحقق خفيف الوزن

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

يعمل هذا التحقق الخفيف على تسهيل المعاملات من نظير إلى نظير ويقلل الاعتماد على مقدمي الخدمات المركزيين، مما يعزز اللامركزية.

قابلية التوسع

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

الخصوصية

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

بالإضافة إلى ذلك، يدعم RGB الإخراج الأعمى، مما يعني أن الدافعين لا يمكنهم تحديد UTXO الذي سيتم دفع أصول RGB إليه، مما يزيد من تعزيز الخصوصية ومقاومة الرقابة.

العيوب

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

يناقش المجتمع إمكانية إعادة استخدام الحسابات التاريخية، وقد تتيح براهين ZK التكرارية إمكانية التحقق من الحالة بحجم ووقت ثابتين.

التراكمي

نظرة عامة

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

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

مع نضج حل التحديثات المجمعة لنظام Ethereum البيئي بشكل متزايد، يبدأ نظام Bitcoin البيئي أيضًا في استكشاف التحديثات المجمعة. ومع ذلك، فإن الاختلاف الرئيسي بين Bitcoin و Ethereum هو الافتقار إلى القدرة على البرمجة لإجراء الحسابات المطلوبة لإنشاء مجموعات مجمعة على السلسلة. نعمل حاليًا بشكل أساسي على تنفيذ مجموعات Sovereign Rollups وOP Rollups.

التصنيف

يمكن تقسيم المجموعات المجمعة إلى فئتين رئيسيتين: مجموعات متفائلة (مجموعات متفائلة) ومجموعات صلاحية (مجموعات ZK). يكمن الاختلاف الرئيسي في طريقة التحقق من انتقال الحالة.

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

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

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

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

الاستكشاف والمناقشة

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

المجموعات السيادية

في 5 مارس 2023، تم الإعلان عن Rollkit كأول إطار عمل يدعم عمليات التجميع السيادية للبيتكوين. يمكن لمنشئي مجموعات التحديثات السيادية استخدام Rollkit لنشر بيانات التوفر على Bitcoin.

Rollkit مستوحى من Ordinals ويستخدم معاملات Taproot لنشر البيانات. يمكن أن تحتوي معاملات Taproot التي تتوافق مع معايير mempool العامة على ما يصل إلى 390 كيلو بايت من البيانات، في حين أن معاملات Taproot غير القياسية التي يتم نشرها مباشرة بواسطة القائمين بالتعدين يمكن أن تحتوي على ما يقرب من 4 ميجابايت من البيانات العشوائية.

توفر Rollkit بشكل أساسي واجهة لقراءة وكتابة البيانات على Bitcoin، وتوفر خدمات وسيطة لتحويل Bitcoin إلى طبقة DA.

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

مجموعات OP ومجموعات الصلاحية

على الرغم من أن العديد من مشاريع Bitcoin Layer 2 تدعي أنها ZK Rollups، إلا أنها أقرب بشكل أساسي إلى OP Rollups وتتضمن تقنية إثبات الصلاحية . لكن قدرات البرمجة الحالية للبيتكوين ليست كافية لدعم التحقق المباشر من إثبات الصلاحية.

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

فكيف يعمل إثبات الصلاحية؟ تنشر معظم المشاريع تناقضات البيانات وإثباتات صحة المعاملات المجمعة إلى Bitcoin بتنسيق الإدراج واستخدام BitVM للتحقق المتفائل. في هذا المخطط، يعمل مشغل الجسر كاتحاد، لإدارة ودائع المستخدمين. قبل قيام المستخدم بإجراء إيداع، يقوم الاتحاد بالتوقيع مسبقًا على UTXO للتأكد من أنه لا يمكن المطالبة بالإيداع بشكل قانوني إلا من قبل المشغل. بمجرد التوقيع المسبق، يتم قفل BTC في عنوان Taproot متعدد التوقيع N/N.

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

هذه العملية هي في الأساس نفس عملية OP Rollup، حيث يكون افتراض الثقة هو 1/N - طالما أن أحد المدققين صادق، فإن البروتوكول آمن. أما بالنسبة لإثبات الصلاحية، فالغرض ليس تسهيل التحقق على شبكة البيتكوين، ولكن جعل التحقق أسهل للعقد الفردية.

ومع ذلك، قد يواجه التنفيذ الفني لهذا الحل تحديات. في مشروع OP Rollup الخاص بـ Ethereum، تم تطوير Arbitrum لسنوات عديدة، ولا يزال إثبات الاحتيال الخاص به يتم تقديمه بواسطة العقد المرخصة، ولا يزال Optimism لا يدعم إثبات الاحتيال، مما يوضح صعوبة التنفيذ.

بدعم من Bitcoin Covenant، يمكن إجراء عمليات التوقيع المسبق في جسر BitVM بشكل أكثر كفاءة، وهو الأمر الذي لا يزال يتعين على المجتمع الوصول إليه.

من منظور سمات الأمان، من خلال إرسال تجزئة الكتلة المجمعة إلى Bitcoin، تكتسب Bitcoin القدرة على مقاومة إعادة التنظيم والإنفاق المزدوج، بينما يوفر Optimistic Bridge افتراض أمان 1/N. ومن المتوقع أيضًا أن يتم تحسين مقاومة الرقابة في Optimistic Bridge.

الاستنتاج: الطبقة الثانية ليست حلاً سحريًا

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

بدون ترقيات SegWit وأقفال الوقت، لا يمكن إنشاء شبكة Lightning بنجاح؛ بدون ترقيات Taproot، لا يمكن تقديم الالتزامات في RGB بكفاءة بدون OP_CAT والمواثيق الأخرى، ستكون الصلاحية على مجموعات Bitcoin مستحيلة...

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

في مقالتنا التالية، سنستكشف محاولات تعزيز قابلية برمجة البيتكوين.