“`html

بيتكوين الطبقة الثانية: سلاسل الحالات (Statechains)

هذا هو المقال الثاني في سلسلة مقالاتنا حول الطبقة الثانية من بيتكوين. في هذا المقال، سنتناول بروتوكول سلاسل الحالات (Statechains)، الذي صممه في الأصل Ruben Somsen ونفذته شركة CommerceBlock.

سلاسل الحالات هي بروتوكول أصلي للطبقة الثانية تم تطويره في البداية بواسطة Ruben Somsen في عام 2018، بالاعتماد على اقتراح eltoo (أو LN Symmetry). في عام 2021، تم بناء نسخة مختلفة من الاقتراح الأصلي، وهي Mercury، بواسطة CommerceBlock. وفي عام 2024، تم بناء تكرار آخر من مخطط Mercury الأصلي، وهو Mercury Layer.

يُعد بروتوكول سلاسل الحالات أكثر تعقيدًا بعض الشيء للمناقشة مقارنة بالأنظمة الأخرى مثل Ark أو Lightning، نظرًا لتنوع الاختلافات الممكنة بين التصميم المقترح الأصلي، والتصميمين اللذين تم تنفيذهما فعليًا، والتصاميم الأخرى الممكنة التي تم اقتراحها بشكل غير رسمي.

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

الفكرة العامة لسلسلة الحالات هي القدرة على نقل ملكية وحدة UTXO بأكملها بين مستخدمين مختلفين خارج السلسلة، بتسهيل من المنسق. لا يوجد أي متطلب لسيولة مستلمة مثل Lightning، أو أن يوفر خادم المنسق أي سيولة مثل Ark.

للبدء، سننظر في البروتوكول الأصلي الذي اقترحه Ruben Somsen.

سلسلة الحالات الأصلية

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

تم بناء التصميم الأصلي على eltoo باستخدام ANYPREVOUT، ولكن الخطط الحالية لكيفية تمكين نفس الوظائف تستفيد من CHECKTEMPLATEVERIFY و CHECKSIGFROMSTACK (شرح عالي المستوى لذلك موجود في نهاية مقال CHECKSIGFROMSTACK). الفكرة الأساسية هي سكربت يمكن معاملة موقعة مسبقًا من إنفاق أي UTXO يحتوي على هذا السكربت ويقفل الكمية المناسبة من البيتكوين، بدلاً من أن يكون مرتبطًا بإنفاق UTXO محدد واحد.

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

باستخدام هذه المحفظة متعددة التوقيع، يوقع بوب والمنسق معاملة تنفق تلك العملة وتنشئ UTXO يمكن إنفاقها إما بأي معاملة أخرى موقعة بالمفتاح الانتقالي ومفتاح المنسق باستخدام LN Symmetry، أو بمفتاح بوب الفريد بعد فترة زمنية محددة (timelock). يمكن لبوب الآن تمويل المحفظة متعددة التوقيع بالمبلغ المناسب، وهكذا تم إنشاء سلسلة الحالات.

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

يتم جعل كل هذا “ذريًا” (atomic) باستخدام التوقيعات التكيفية (adapter signatures). هذه التوقيعات يتم تعديلها بطريقة معينة باستخدام قطعة بيانات عشوائية تجعلها غير صالحة، ولكن يمكن جعلها صالحة مرة أخرى بمجرد أن يحصل حامل التوقيع على تلك القطعة من المعلومات. يتم توقيع جميع الرسائل والمعاملة الجديدة الموقعة مسبقًا باستخدام التوقيعات التكيفية، وتصبح صالحة atomically في نفس الوقت من خلال إطلاق بيانات التكيف.

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

Mercury و Mercury Layer

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

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

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

هيكل المعاملة الموقعة مسبقًا لـ Mercury و Mercury Layer لا يمكنه استخدام LN Symmetry، حيث أن هذا غير ممكن بدون softfork. بدلاً من ذلك، اختارت CommerceBlock استخدام أقفال زمنية متناقصة (decrementing timelocks). المعاملة الموقعة مسبقًا للمالك الأصلي يتم قفلها زمنيًا باستخدام nLocktime إلى وقت بعيد في المستقبل من نقطة إنشاء سلسلة الحالات. مع كل مستخدم لاحق يستلم سلسلة الحالات أثناء التحويل، تكون قيمة nLocktime لمعاملته أقصر بفترة زمنية محددة مسبقًا من المالك السابق. هذا يضمن أن المالك السابق غير قادر حتى على محاولة تقديم معاملته على السلسلة قبل أن يتمكن المالك الحالي من ذلك، ولكنه يعني أيضًا أنه في النهاية عند نقطة ما، يجب على المالك الحالي إغلاق سلسلة الحالات على السلسلة قبل أن تبدأ معاملات المالكين السابقين في أن تصبح صالحة.

الفرق الرئيسي بين Mercury و Mercury Layer هو كيفية توقيع هذه المعاملات. في حالة Mercury، يرى خادم المنسق ببساطة المعاملة المقترحة، يتحقق منها، ثم يوقعها. يستخدم Mercury Layer بروتوكول توقيع أعمى (blind-signing)، مما يعني أنه لا يرى فعليًا أي تفاصيل للمعاملة التي يوقعها. هذا يستلزم أن يقوم الخادم بتتبع سلاسل الحالات باستخدام سجلات مجهولة الهوية على الخادم، ومفتاح تفويض خاص بالمالك الحالي حتى يتأكدوا من أنهم يوقعون فقط على تحويلات صالحة.

التآزر مع الطبقات الأخرى

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

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

خلاصة

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

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

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

هذا المقال بيتكوين الطبقة الثانية: سلاسل الحالات ظهر أولاً على Bitcoin Magazine وتمت كتابته بواسطة Shinobi.

## seo_title
بيتكوين الطبقة الثانية: فهم سلاسل الحالات (Statechains) بعمق
## seo_description
استكشف سلاسل الحالات (Statechains)، بروتوكول الطبقة الثانية من بيتكوين الذي يسمح بنقل وحدات UTXO خارج السلسلة بكفاءة وسيولة، مع التركيز على نماذج الثقة المختلفة وتطبيقاتها مثل Mercury.
## seo_tags
بيتكوين,الطبقة الثانية,سلاسل الحالات,Statechains,Lightning,Ark,eltoo,CommerceBlock,Shinobi,UTXO,خارج السلسلة,Off-chain,MPC,Multi-Party Computation,Softfork,Trust Minimized,BTC,تكنولوجيا البلوك تشين,العملات المشفرة
## seo_keywords
سلاسل الحالات بيتكوين,ما هي سلاسل الحالات,Statechains شرح,Bitcoin Layer 2 Statechains,Mercury Statechains,CommerceBlock Statechains,بروتوكولات الطبقة الثانية بيتكوين,نقل UTXO خارج السلسلة,نموذج الثقة Statechains,مقارنة Statechains Lightning Ark,تكنولوجيا البلوك تشين بيتكوين
## seo_keypoints
– سلاسل الحالات هي بروتوكول Layer 2 لنقل UTXO خارج السلسلة.
– تم تصميمها أصلاً بواسطة Ruben Somsen ونفذت بواسطة CommerceBlock (Mercury و Mercury Layer).
– تعتمد على خادم منسق مركزي ولكنها توفر ضمانات أمنية قوية عبر التوقيعات المسبقة وتقليل الثقة.
– تستخدم التوقيعات التكيفية (Adapter Signatures) أو الحوسبة متعددة الأطراف (MPC) لتمكين التحويلات الذرية.
– تختلف تطبيقات Mercury عن التصميم الأصلي باستخدام الأقفال الزمنية المتناقصة بدلاً من LN Symmetry ولتوحيد MPC.
– يمكن دمج سلاسل الحالات مع قنوات Lightning أو دفعات Ark.
– واجهت صعوبة في تحقيق تبني واسع النطاق في العالم الحقيقي حتى الآن.
## seo_slug
بيتكوين-الطبقة-الثانية-سلاسل-الحالات
“`