سلاسل بلازما (Plasma)

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

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

المتطلبات الأساسية

يجب أن يكون لديك فهم جيد لجميع المواضيع الأساسية وفهم عالي المستوى لـ قابلية التوسّع في إيثريوم.

ما هي بلازما (Plasma)؟

بلازما هي إطار عمل لتحسين قابلية التوسّع في شبكات البلوك تشين العامة مثل إيثريوم. كما هو موضح في الورقة البيضاء الأصلية لبلازما (opens in a new tab)، تُبنى سلاسل بلازما فوق البلوك تشين أخرى (تُسمى "السلسلة الجذرية"). تمتد كل "سلسلة فرعية" من السلسلة الجذرية وتُدار عمومًا بواسطة عقد ذكي منشور على السلسلة الأم.

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

كيف تعمل بلازما؟

المكونات الأساسية لإطار عمل بلازما هي:

الحوسبة خارج السلسلة

تقتصر سرعة المعالجة الحالية لإيثريوم على حوالي 15-20 معاملة في الثانية، مما يقلل من إمكانية قابلية التوسّع على المدى القصير للتعامل مع المزيد من المستخدمين. توجد هذه المشكلة بشكل أساسي لأن آلية الإجماع في إيثريوم تتطلب العديد من عقد الند للند (peer-to-peer) للتحقق من كل تحديث لـ حالة البلوك تشين.

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

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

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

التزامات الحالة

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

مخطط الالتزام (opens in a new tab) هو تقنية تشفير للالتزام بقيمة أو بيان دون الكشف عنه لطرف آخر. الالتزامات "مُلزمة" بمعنى أنه لا يمكنك تغيير القيمة أو البيان بمجرد الالتزام به. تأخذ التزامات الحالة في بلازما شكل "جذور ميركل" (Merkle roots) (المشتقة من شجرة ميركل) والتي يرسلها المشغل على فترات إلى عقد بلازما على سلسلة إيثريوم.

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

تعتبر جذور ميركل مهمة لتوفير معلومات حول حالة خارج السلسلة لإيثريوم. يمكنك التفكير في جذور ميركل على أنها "نقاط حفظ": يقول المشغل، "هذه هي حالة سلسلة بلازما في النقطة الزمنية x، وهذا هو جذر ميركل كإثبات." يلتزم المشغل بـ الحالة الحالية لسلسلة بلازما بجذر ميركل، ولهذا السبب يُطلق عليه "التزام الحالة".

الدخول والخروج

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

تستخدم بلازما عقدًا رئيسيًا يعمل على إيثريوم لمعالجة دخول وخروج المستخدمين. هذا العقد الرئيسي مسؤول أيضًا عن تتبع التزامات الحالة (الموضحة سابقًا) ومعاقبة السلوك غير النزيه عبر إثباتات الاحتيال (المزيد عن هذا لاحقًا).

الدخول إلى سلسلة بلازما

للدخول إلى سلسلة بلازما، سيتعين على أليس (المستخدم) إيداع ETH أو أي رمز ERC-20 في عقد بلازما. يقوم مشغل بلازما، الذي يراقب إيداعات العقد، بإعادة إنشاء مبلغ مساوٍ لإيداع أليس الأولي ويطلقه إلى عنوانها على سلسلة بلازما. يُطلب من أليس الإقرار بتلقي الأموال على السلسلة الفرعية ويمكنها بعد ذلك استخدام هذه الأموال في المعاملات.

الخروج من سلسلة بلازما

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

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

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

يجب عليها أيضًا تقديم إثبات ميركل للتحقق من أن المعاملة التي أنشأت أموالها على سلسلة بلازما قد تم تضمينها في بلوك. هذا ضروري لتكرارات بلازما، مثل Plasma MVP (opens in a new tab)، التي تستخدم نموذج مخرجات المعاملات غير المنفقة (UTXO) (opens in a new tab).

البعض الآخر، مثل Plasma Cash (opens in a new tab)، يمثل الأموال كـ رموز غير قابلة للاستبدال بدلاً من UTXOs. يتطلب السحب، في هذه الحالة، إثبات ملكية الرموز على سلسلة بلازما. يتم ذلك عن طريق إرسال أحدث معاملتين تتضمنان الرمز وتقديم إثبات ميركل للتحقق من تضمين تلك المعاملات في بلوك.

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

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

التحكيم في النزاعات

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

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

لمنع السحب، سيقوم بوب بإنشاء إثبات الاحتيال من خلال تقديم دليل على إنفاق أليس لـ UTXO المذكور في معاملة سابقة وإثبات ميركل لتضمين المعاملة في بلوك. تعمل نفس العملية في Plasma Cash — سيحتاج بوب إلى تقديم دليل على أن أليس نقلت سابقًا الرموز التي تحاول سحبها.

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

مشكلة الخروج الجماعي في بلازما

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

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

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

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

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

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

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

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

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

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

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

إيجابيات وسلبيات بلازما

بلازما مقابل بروتوكولات قابلية التوسّع في الطبقة الثانية

بينما كانت بلازما تُعتبر في السابق حلاً مفيدًا لـ قابلية التوسّع في إيثريوم، فقد تم التخلي عنها منذ ذلك الحين لصالح بروتوكولات قابلية التوسّع في الطبقة الثانية (L2). تعالج حلول قابلية التوسّع في الطبقة الثانية العديد من مشاكل بلازما:

الكفاءة

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

دعم العقود الذكية

مشكلة أخرى في إطار عمل بلازما كانت عدم القدرة على دعم تنفيذ العقود الذكية لإيثريوم (opens in a new tab). نتيجة لذلك، تم بناء معظم تطبيقات بلازما في الغالب للمدفوعات البسيطة أو تبادل رموز ERC-20.

على العكس من ذلك، يتوافق الرول أب التفائلي مع آلة إيثريوم الافتراضية ويمكنه تشغيل عقد ذكي أصلي لإيثريوم، مما يجعله حلاً مفيدًا و_آمنًا_ لتوسيع نطاق التطبيقات اللامركزية. وبالمثل، تجري الخطط لـ إنشاء تطبيق المعرفة الصفرية لآلة إيثريوم الافتراضية (zkEVM) (opens in a new tab) والذي سيسمح لـ الرول أب المعتمد على إثباتات المعرفة الصفرية (ZK-rollups) بمعالجة المنطق التعسفي وتنفيذ العقود الذكية.

عدم توفر البيانات

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

مشكلة الخروج الجماعي

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

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

كيف تختلف بلازما عن السلاسل الجانبية والتجزئة؟

بلازما مقابل السلاسل الجانبية

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

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

بلازما مقابل التجزئة

تنشر كل من سلاسل بلازما وسلاسل التجزئة (shard chains) إثباتات تشفيرية بشكل دوري على الشبكة الرئيسية لإيثريوم. ومع ذلك، كلاهما له خصائص أمان مختلفة.

تلتزم سلاسل التجزئة بـ "رؤوس التجميع" (collation headers) للشبكة الرئيسية التي تحتوي على معلومات مفصلة حول كل جزء من البيانات. تتحقق العقد على الشبكة الرئيسية من صحة أجزاء البيانات وتفرضها، مما يقلل من إمكانية انتقالات التجزئة غير الصالحة ويحمي الشبكة من النشاط الضار.

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

ملاحظة أن التجزئة في البلوك تشين لإيثريوم لم تعد مدرجة في خريطة الطريق. لقد تم استبدالها بـ قابلية التوسّع عبر الرول أب وDanksharding.

استخدام بلازما

توفر مشاريع متعددة تطبيقات لبلازما يمكنك دمجها في التطبيقات اللامركزية الخاصة بك:

• Polygon (opens in a new tab) (سابقًا Matic Network)

قراءة إضافية

• تعلم بلازما (opens in a new tab)
• تذكير سريع بما يعنيه "الأمان المشترك" ولماذا هو مهم جدًا (opens in a new tab)
• السلاسل الجانبية مقابل بلازما مقابل التجزئة (opens in a new tab)
• فهم بلازما، الجزء الأول: الأساسيات (opens in a new tab)
• حياة وموت بلازما (opens in a new tab)

هل تعرف موردًا مجتمعيًا ساعدك؟ قم بتعديل هذه الصفحة وأضفه!

برامج تعليمية: سلاسل بلازما على إيثريوم

• كتابة بلازما خاصة بتطبيق تحافظ على الخصوصية – بناء تطبيق بلازما يحافظ على الخصوصية باستخدام إثباتات المعرفة الصفرية والمكونات خارج السلسلة.