حجب البيانات وإثبات الاحتيال: لماذا لا تدعم البلازما العقود الذكية

المؤلف: فاوست ، المهوس web3

أما بالنسبة لسبب دفن البلازما لفترة طويلة ، ولماذا سيدعم فيتاليك بقوة Rollup ، فإن القرائن تشير بشكل أساسي إلى نقطتين: تنفيذ DA خارج السلسلة على سلسلة Ethereum غير موثوق به ، ومن السهل أن يحدث حجب البيانات ، وبمجرد حدوث حجب البيانات ، يصعب تطوير إثبات الاحتيال ؛ ** هاتان النقطتان تجعلان البلازما في الأساس UTXO فقط أو النماذج التقريبية.

لفهم هاتين النقطتين الأساسيتين ، لنبدأ ب DA والاحتفاظ بالبيانات. DA تعني توفر البيانات ، والتي تترجم حرفيا إلى توافر البيانات ، ويساء استخدامها الآن من قبل العديد من الأشخاص ، لدرجة أنه يتم الخلط بينها وبين “يمكن التحقق من البيانات التاريخية”. ولكن في الواقع ، تعد “البيانات التاريخية” و “إثبات التخزين” من المشكلات طويلة الأمد التي تم حلها بواسطة أمثال Filecoin و Arweave. وفقا لمؤسسة Ethereum و Celestia ، فإن قضية DA تتعلق فقط بسيناريوهات حجب البيانات. **

****شجرة ميركل وجذر ميركل ودليل ميركل ****

لتوضيح ما تعنيه هجمات حجب البيانات ومشاكل DA ، نحتاج أولا إلى التحدث بإيجاز عن Merkle Root و Merkle Tree. ** في Ethereum ، أو معظم السلاسل العامة ، يتم استخدام بنية بيانات تشبه الشجرة تسمى Merkle Tree لتكون بمثابة ملخص / دليل لحالة الحساب بأكمله ، أو لتسجيل المعاملات التي تم تعبئتها داخل كل كتلة.

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

(** السجل الموجود أسفل الرسم البياني هو مجموعة البيانات الأصلية المقابلة لعقدة الورقة) **

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

على سبيل المثال ، إذا كان Li Gang يعرف فقط قيمة جذر Merkle في الشكل ، فهو لا يعرف البيانات التي تحتوي عليها شجرة Merkle الكاملة. نحتاج إلى أن نثبت ل Li Gang أن السجل 3 مرتبط بالفعل بالجذر الموجود في الصورة ، أو أن تجزئة السجل 3 موجودة على شجرة Merkle المقابلة للجذر.

نحتاج فقط إلى إرسال Record3 وكتل الملخص الثلاثة المميزة باللون الرمادي إلى Li Gang ، بدلا من الالتزام بشجرة Merkle بأكملها أو جميع عقد أوراقها ، وهي بساطة Merkle Proof. عندما يحتوي السجل الأساسي لشجرة Merkle على عدد كبير من الأوراق ، مثل 2 إلى قوة كتلتي بيانات (حوالي 1 مليون) ، يحتاج Merkle Proof فقط إلى احتواء 21 كتلة بيانات على الأقل.

(يمكن أن تشكل كتلة البيانات 30 و H2 في الشكل دليلا على Merkle ، مما يثبت أن كتلة البيانات 30 موجودة على شجرة Merkle المقابلة ل H0) **

في Bitcoin أو Ethereum أو الجسور عبر السلاسل ، غالبا ما يتم استخدام “بساطة” Merkle Proof. العقدة الخفيفة التي نعرفها هي في الواقع Li Gang المذكورة أعلاه ، والتي تتلقى فقط رأس الكتلة من العقدة الكاملة ، وليس الكتلة الكاملة. من المهم التأكيد هنا على أن Ethereum تستخدم شجرة Merkle تسمى State Trie ، والتي تعمل كملخص للحساب بأكمله. يتغير جذر Merkle الخاص ب State Trie ، المسمى StateRoot ، كلما تغيرت حالة أحد الحسابات المرتبطة ب State Trie.

في رأس كتلة Ethereum ، سيتم تسجيل StateRoot ، كما سيتم تسجيل جذر Merkle (المشار إليه باسم Txn Root) لشجرة المعاملة. إذا كانت الكتلة 100 تحتوي على 300 معاملة ، فإن أوراق شجرة التداول تمثل 300 Txn هذه.

الفرق الآخر هو أن الكمية الإجمالية للبيانات في State Trie كبيرة بشكل خاص ، وأن ورقتها الأساسية تتوافق مع جميع العناوين في سلسلة Ethereum (في الواقع ، هناك العديد من تجزئات الحالة القديمة) ، لذلك لن يتم نشر مجموعة البيانات الأصلية المقابلة ل State Trie إلى الكتلة ، سيتم تسجيل StateRoot فقط في رأس الكتلة. مجموعة البيانات الأصلية لشجرة المعاملات هي بيانات Txn في كل كتلة ، وسيتم تسجيل TxnRoot للشجرة في رأس الكتلة.

نظرا لأن العقدة الخفيفة تتلقى رأس الكتلة فقط ، ولا تعرف سوى StateRoot و TxnRoot ، ولا يمكنها استنتاج شجرة Merkle الكاملة بناء على الجذر (يتم تحديد ذلك حسب طبيعة شجرة Merkle ووظيفة التجزئة) ، لا يمكن للعقدة الخفيفة معرفة بيانات المعاملة الموجودة في الكتلة ، ولا تعرف التغييرات التي حدثت على الحساب المقابل ل State Trie. **

إذا أراد Wang Qiang أن يثبت لعقدة خفيفة (Li Gang المذكورة سابقا) أن الكتلة 100 تحتوي على معاملة معينة ، ومن المعروف أن العقدة الخفيفة تعرف رأس كتلة الكتلة 100 وتعرف TxnRoot ، فإن المشكلة المذكورة أعلاه تترجم إلى: إثبات أن Txn هذا موجود على شجرة Merkle المقابلة ل TxnRoot. في هذا الوقت ، يحتاج Wang Qiang فقط إلى تقديم دليل Merkle المقابل.

في العديد من الجسور عبر السلاسل القائمة على حلول العميل الخفيفة ، غالبا ما يتم استخدام خفة وبساطة العقد الخفيفة و Merkle Proof المذكورة أعلاه. على سبيل المثال ، ستقوم جسور ZK مثل Map Protocol بإعداد عقد على سلسلة ETH لتلقي رؤوس الكتلة من سلاسل أخرى (مثل Polygon). عندما يرسل Relayer رأس الكتلة 100 من Polygon إلى العقد على سلسلة ETH ، سيتحقق العقد من صحة الرأس (مثل ما إذا كان يحتوي على توقيعات كافية من 2/3 عقد POS في شبكة Polygon).

إذا كان الرأس صالحا وأعلن المستخدم أنه بدأ Txn عبر السلسلة من Polygon إلى ETH ، تعبئة Txn في الكتلة 100 من Polygon. يحتاج فقط إلى إثبات من خلال Merkle Proof أن Txn عبر السلسلة الذي بدأه يمكن أن يتوافق مع TxnRoot لرأس الكتلة 100 (بمعنى آخر ، يثبت أن Txn عبر السلسلة الذي بدأه لديه سجل في الكتلة 100 من Polygon). ومع ذلك ، سيستخدم جسر ZK براهين المعرفة الصفرية لضغط مقدار الحساب المطلوب للتحقق من Merkle Proof ، مما يقلل من تكلفة التحقق من عقود الجسور عبر السلسلة.

DA وقضايا هجوم الاحتفاظ بالبيانات

بعد الحديث عن Merkle Tree و Merkle Root و Merkle Proof ، دعنا نعود إلى مشكلة هجوم حجب البيانات والبيانات المذكورة في بداية المقالة ، والتي تم استكشافها قبل عام 2017 ، وورقة Celestia الأصلية أركرت أصل مشكلة DA. في وثيقة 2017 ~ 18 ، تحدث فيتاليك نفسه عن كيف يمكن للحاصرات إخفاء أجزاء معينة من البيانات من الكتلة عمدا ونشر كتل غير مكتملة ، بحيث لا يمكن للعقد الكاملة تأكيد صحة تنفيذ المعاملة / انتقالات الحالة.

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

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

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

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

ملاحظة: أخذ عينات بيانات DA (DAS) و Celestia ليسا محور هذه المقالة ، يمكن للقراء المهتمين قراءة المقالة السابقة من Geek Web3: “المفاهيم الخاطئة حول توفر البيانات: DA = نشر البيانات ≠ استرجاع البيانات التاريخية”

دليل الاحتيال في البلازما

ببساطة ، البلازما هو حل تحجيم ينشر فقط رؤوس كتل الطبقة 2 إلى الطبقة 1 ، ويتم نشر بيانات DA خارج رأس الكتلة (مجموعة بيانات المعاملة الكاملة / تغيير الحالة لكل حساب) فقط خارج السلسلة. بمعنى آخر ، تشبه البلازما جسرا عبر السلسلة يعتمد على العملاء الخفيفين ، وينفذ عميلا خفيفا من الطبقة 2 بعقد على سلسلة ETH ، وعندما يعلن المستخدم أنه يريد عبور الأصول من L2 إلى L1 ، يجب عليه تقديم دليل Merkle لإثبات أنه يمتلك الأصول بالفعل.

** منطق التحقق للأصول التي تمتد من L2 إلى L1 مشابه لجسر ZK المذكور أعلاه ، باستثناء أن نموذج جسر البلازما يعتمد على أدلة الاحتيال بدلا من براهين ZK ، وهو أقرب إلى ما يسمى “الجسر المتفائل”. ** لا يتم إصدار طلبات السحب من L2 إلى L1 في شبكة البلازما على الفور ، ولكن لها “فترة تحدي” ، أما بالنسبة لغرض فترة التحدي ، فسوف نوضح أدناه.

لا تحتوي البلازما على متطلبات صارمة لإصدار البيانات / DA ، حيث يقوم جهاز التسلسل / المشغل فقط ببث كل كتلة L2 خارج السلسلة ، والعقد التي ترغب في الحصول على كتلة L2 تفعل ذلك بمفردها. بعد ذلك ، سينشر جهاز التسلسل رأس كتلة L2 إلى الطبقة 1. على سبيل المثال ، يبث جهاز التسلسل كتلة 100 خارج السلسلة ثم ينشر رأس الكتلة على السلسلة. إذا كان المربع 100 يحتوي على معاملات غير صالحة ، فيمكن لأي عقدة بلازما تقديم دليل Merkle إلى العقد على ETH قبل نهاية “فترة التحدي” لإثبات أن رأس الكتلة 100 يمكن ربطه بمعاملة غير صالحة ، وهو سيناريو تغطيه أدلة الاحتيال.

تشمل حالات استخدام البلازما المقاومة للاحتيال أيضا ما يلي:

1. لنفترض أن تقدم شبكة البلازما وصل إلى الكتلة 200 ، وبدأ المستخدم A بيان سحب ، قائلا إن لديه 10 ETH في الكتلة 100. ولكن في الواقع ، أنفق المستخدم A ETH على الحساب بعد الكتلة 100.

لذا ، فإن سلوك A هو في الواقع إنفاق 10 ETH ، وإعلان أنه كان لديه 10 ETH في الماضي ، ومحاولة سحب ETH. هذا هو “السحب المزدوج” الكلاسيكي ، الإنفاق المزدوج. في الوقت الحالي ، يمكن لأي شخص تقديم إثبات Merkle لإثبات أحدث حالة أصول للمستخدم A ، ولا يفي ببيان السحب الخاص به ، أي لإثبات أن A لم يكن لديه بيان سحب بعد الكتلة 100 (مخططات البلازما المختلفة لها طرق إثبات غير متسقة لهذا الموقف ، ونموذج عنوان الحساب أكثر إزعاجا بكثير من إثبات الإنفاق المزدوج ل UTXO).

2. إذا كان مخطط بلازما يعتمد على نموذج UTXO (وهو ما كان عليه الحال بشكل أساسي في الماضي) ، فلا يوجد StateRoot في رأس الكتلة ، فقط TxnRoot (لا يدعم UTXO نموذج عنوان الحساب على غرار Ethereum ، ولا يحتوي على تصميم حالة عالمي مثل State Trie). بمعنى آخر ، السلسلة التي تتبنى نموذج UTXO لديها سجلات معاملات فقط ، وليس سجلات حالة.

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

3. بالنسبة لمخططات البلازما المتوافقة مع EVM / التي تدعم State Trie ، من الممكن أن يقوم جهاز التسلسل بإرسال StateRoot غير صالح ، على سبيل المثال ، بعد تنفيذ المعاملة الواردة في الكتلة 100 ، يجب تحويل StateRoot إلى ST + ، لكن جهاز التسلسل يرسل ST- إلى الطبقة 1.

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

الاحتفاظ بالبيانات والخروج من اللعبة ****

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

في هذا الوقت ، يمكن لجهاز التسلسل سرقة أصول المستخدم ، مثل تحويل جميع العملات المعدنية من الحساب A إلى الحساب B ، ثم تحويل الأموال من الحساب B إلى C ، وأخيرا بدء السحب باسم C. الحسابات B و C مملوكة لجهاز التسلسل ، ونقل B->C غير ضار حتى لو تم نشره للجمهور.** لكن يمكن لجهاز التسلسل حجب بيانات النقل غير الصالح ل A->B ، ولا يمكن للأشخاص إثبات وجود مشكلة في مصدر أصول B و C ** (لإثبات أن مصدر أصول B يمثل مشكلة ، من الضروري الإشارة إلى أن التوقيع الرقمي ل “Txn معين تم نقله إلى B” غير صحيح).

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

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

في هذا الوقت ، يمكن للأشخاص رؤية رأس الكتلة المقابل فقط ، لكنهم لا يعرفون ما هو موجود في الكتلة ، ولا يعرفون ما أصبحت عليه أصول حساباتهم ، لذلك سيبدأون بشكل جماعي بيان سحب ويحاولون الانسحاب باستخدام Merkle Proof المقابل للكتلة التاريخية ، ** مما يؤدي إلى سيناريو متطرف يسمى “لعبة الخروج” ، والذي سيؤدي إلى “تدافع” ، مما سيجعل الطبقة 1 مزدحمة بشكل خطير ، وسيظل يتسبب في تلف أصول بعض الأشخاص ** (الأشخاص الذين لا يتلقون إشعارات صادقة للعقدة أو لا يمررون تويتر لن يعرفوا أن جهاز التسلسل يسرق العملات المعدنية.)

لذلك ، تعد البلازما حلا غير موثوق به لتوسيع نطاق Layer2 ، وبمجرد حدوث هجوم حجب البيانات ، سيؤدي ذلك إلى تشغيل “لعبة خروج” ، والتي يسهل على المستخدمين تكبدها خسائر ، وهو سبب رئيسي للتخلي عنها. **

أسباب صعوبة دعم البلازما للعقود الذكية ****

بعد الحديث عن Exit Game وقضايا الاحتفاظ بالبيانات ، دعونا نلقي نظرة على سبب صعوبة دعم البلازما للعقود الذكية ، وذلك أساسا لسببين:

أولا ، إذا كان أحد أصول عقد Defi ، فمن يجب أن يسحبه إلى الطبقة 1؟ نظرا لأن هذا يقوم بشكل أساسي بترحيل حالة العقد من الطبقة 2 إلى الطبقة 1 ، افترض أن شخصا ما يتقاضى 100 ETH إلى تجمع LP الخاص ب DEX ، ثم يقوم جهاز تسلسل البلازما بالشر ، ويريد الناس الانسحاب بشكل عاجل ، في هذا الوقت ، لا يزال عقد 100 ETH الخاص بالمستخدم خاضعا لعقد DEX ، من يجب أن يذكر هذه الأصول إلى الطبقة 1 في هذا الوقت؟

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

لذا ، ماذا لو أنشأنا مالكا لعقد DEX مقدما ، مما سمح له بوضع أصول العقد على L1 في حالة الطوارئ؟ من الواضح أن هذا سيمنح مالك العقد ملكية الأصول العامة ، ويمكنه وضع هذه الأصول على L1 في أي وقت والهرب ، ألن يكون ذلك فظيعا؟

من الواضح أن ما يجب فعله بهذه “الممتلكات العامة” التي تهيمن عليها عقود Defi هو رعد كبير. ** هذا ينطوي في الواقع على مشكلة توزيع السلطة العامة ، والتي تحدث عنها Xiangma سابقا في مقابلة مع “من الصعب على السلاسل العامة عالية الأداء القيام بأشياء جديدة ، والعقود الذكية تنطوي على توزيع السلطة”.

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

على سبيل المثال ، لنفترض أن البلازما تتبنى نموذج عنوان حساب Ethereum ، وتدعم العقود الذكية ، ولديها خلاط عملات معدنية ، وتودع حاليا 100 ETH ، ويتم التحكم في مالك خلاط العملات بواسطة Bob ؛

لنفترض أن بوب سحب 50 ETH من الخلاط في الكتلة 100. بعد ذلك ، بدأ بوب بيان الانسحاب وعبر 50 ETH إلى الطبقة 1 ؛

بعد ذلك ، يستخدم بوب لقطة من حالة العقد السابقة (على سبيل المثال ، الكتلة 70) لترحيل الحالة السابقة للخلاط إلى الطبقة 1 ، والتي ستعبر أيضا 100 ETH التي “كان لدى الخلاط ذات مرة” إلى الطبقة 1.

من الواضح أن هذا “تراجع مزدوج” نموذجي ، وهو إنفاق مزدوج. ** تم ذكر 150 ETH بواسطة Bob إلى Layer 1 ، لكن مستخدمي شبكة Layer 2 دفعوا 100 ETH فقط إلى الخلاط / Bob ، وتم سحب 50 ETH من فراغ. هذا يمكن أن يستنزف بسهولة احتياطيات البلازما **. من الناحية النظرية ، يمكن للمرء أن يبدأ إثبات الاحتيال لإثبات أن حالة عقد الخلاط قد تغيرت بعد الكتلة 70.

ولكن إذا كنت ترغب في إظهار دليل على أن عقد Mixer قد تغير بعد Block 70 ، فيجب عليك تشغيل كل Txn المذكورة أعلاه على سلسلة Ethereum للسماح أخيرا لعقد البلازما بتحديد أن حالة عقد Mixer قد تغيرت بالفعل (يتم تحديد سبب تعقيده من خلال بنية البلازما نفسها). إذا كانت كمية Txn كبيرة جدا ، فلن يتم نشر دليل الاحتيال على الطبقة 1 على الإطلاق (سيتجاوز حد الغاز لكتلة واحدة من Ethereum).

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

على سبيل المثال ، عندما تعلن أن لديك 50 ETH في حسابك وتبدأ عملية سحب ، فقد يقوم جهاز التسلسل بمسح حسابك بشكل خاص إلى 0 ، ثم يبدأ في حجب البيانات ، وإرسال StateRoot غير صالح إلى السلسلة ، وإرسال لقطة حالة مقابلة لاتهامك زورا بنفاد الأموال في حسابك. في هذه المرحلة ، لا يمكنك إثبات أن StateRoot و State Snapshot المقدمة من قبل جهاز التسلسل غير صالحة ، لأنه بدأ الاحتفاظ بالبيانات ، ولا تحصل على البيانات الكافية اللازمة لإثبات الاحتيال. **

لمنع ذلك ، تقوم عقدة البلازما أيضا بإعادة تشغيل سجل المعاملات خلال هذه الفترة عند تقديم لقطة للحالة لإثبات أن شخصا ما قد أنفق مرتين ، مما يمنع جهاز التسلسل من حجب البيانات لمنع الآخرين من الانسحاب. في Rollup ، إذا واجهت السحب المزدوج المذكور أعلاه ، فلن تحتاج إلى إعادة تشغيل المعاملة التاريخية من الناحية النظرية ، لأن Rollup لا يواجه مشكلة حجب البيانات وسيقوم “بإجبار” جهاز التسلسل على نشر بيانات DA على السلسلة. ** ستفشل أجهزة تسلسل الإظهار التي ترسل لقطة StateRoot-state غير صالحة إما في التحقق من صحة العقد (ZK Rollup) أو سيتم الطعن فيها قريبا (OP Rollup).

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

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

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