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

من أجل فهم النقطتين الأساسيتين أعلاه، دعونا نبدأ بقضايا DA واحتجاز البيانات. الاسم الكامل لـ DA هو توافر البيانات، والذي يترجم حرفيًا إلى توافر البيانات. وهو يُساء استخدامه الآن بواسطة العديد من الأشخاص إلى درجة أنه يُربك بشكل خطير مع "يمكن التحقق من البيانات التاريخية". ولكن في الواقع، "يمكن التحقق من البيانات التاريخية" و"دليل التخزين" هي مشاكل قامت بحلها بالفعل Filecoin و Arweave. وفقًا لمؤسسة Ethereum و Celestia، تستكشف مسألة DA بشكلٍ نقي سيناريوهات احتفاظ البيانات.

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

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

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

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

(يمكن أن تشكل كتلة البيانات 30 و H2 في الشكل دليل Merkle ، مما يثبت وجود كتلة البيانات 30 على شجرة Merkle المقابلة ل H0)غالبا ما تستخدم "بساطة" Merkle Proof في Bitcoin أو Ethereum أو الجسور عبر السلاسل. العقدة الخفيفة التي نعرفها هي في الواقع Li Gang المذكورة أعلاه. يتلقى فقط رأس الكتلة من العقدة الكاملة ، وليس الكتلة الكاملة. يجب التأكيد هنا على أن Ethereum تستخدم شجرة Merkle تسمى State Trie لتكون بمثابة ملخص لجميع الحسابات. طالما تغيرت حالة الحساب المرتبط ب State Trie ، فإن جذر Merkle لمحاولة الولاية ، المسمى StateRoot ، سيتغير. في رأس كتلة Ethereum ، سيتم تسجيل StateRoot ، وسيتم أيضا تسجيل جذر Merkle لشجرة المعاملة (المشار إليها باسم Txn Root)., أحد الاختلافات بين شجرة المعاملة وشجرة الحالة هو أن البيانات التي تمثلها الأوراق الأساسية مختلفة. إذا كانت الكتلة رقم 100 تحتوي على 300 معاملة ، فإن أوراق شجرة المعاملة تمثل 300 Txn. الفرق الآخر هو أن الحجم الإجمالي لبيانات State Trie كبير للغاية. تتوافق أوراقها السفلية مع جميع العناوين الموجودة على سلسلة Ethereum (في الواقع ، هناك العديد من تجزئات الحالة القديمة) ، لذلك لن يتم إصدار مجموعة البيانات الأصلية المقابلة ل State Trie. في الكتلة ، يتم تسجيل StateRoot فقط في رأس الكتلة. مجموعة البيانات الأصلية لشجرة المعاملات هي بيانات Txn في كل كتلة ، وسيتم تسجيل TxnRoot لهذه الشجرة في رأس الكتلة.

نظرا لأن العقدة الخفيفة تتلقى فقط رأس الكتلة وتعرف فقط StateRoot و TxnRoot ، فلا يمكنها استنتاج شجرة Merkle الكاملة بناء على الجذر (يتم تحديد ذلك من خلال خصائص شجرة Merkle ووظيفة التجزئة) ، لذلك لا يمكن لعقد Light معرفة بيانات المعاملة الموجودة في الكتلة ، ولا يعرفون التغييرات التي حدثت في الحساب المقابل ل State Trie.If أراد Wang Qiang إثبات ل العقدة الخفيفة (Li Gang المذكورة سابقا) أن الكتلة رقم 100 تحتوي على معاملة معينة ، ومن المعروف أن العقدة الخفيفة تعرف رأس الكتلة للكتلة رقم 100 وتعرف TxnRoot ، ثم تتحول المشكلة المذكورة أعلاه إلى: إثبات أن Txn هذا موجود على شجرة Merkle المقابلة ل TxnRoot.At هذه المرة ، يحتاج Wang Qiang فقط إلى تقديم دليل Merkle المقابل.

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

قضايا الهجوم DA وامتناع البيانات

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

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

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

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

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

ملاحظة: ليس تحديد DA Data Sampling (DAS) و Celestia هو تركيز هذه المقالة. يمكن للقراء المهتمين قراءة المقالات السابقة لـ "Geek Web3":“سوء فهم لتوافر البيانات: DA = إصدار البيانات ≠ استرجاع البيانات التاريخية”

دليل الاحتيال الخاص بـ بلازما

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

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

تتضمن سيناريوهات تطبيق البلازما المقاومة للاحتيال أيضا ما يلي:1. افترض أن تقدم شبكة البلازما يصل إلى الكتلة رقم 200. في هذا الوقت ، يبدأ المستخدم A بيان الانسحاب ، قائلا إنه عندما كان في الكتلة رقم 100 ، كان لديه 10 ETH. ولكن في الواقع ، أنفق المستخدم A ETH على حسابه بعد الكتلة 100. لذلك ، فإن سلوك A هو في الواقع: بعد إنفاق 10 ETH ، يعلن أنه كان لديه 10 ETH في الماضي ، ويحاول سحب هذه ETH. هذا هو "السحب المزدوج" النموذجي والإنفاق المزدوج. في هذا الوقت ، يمكن لأي شخص تقديم Merkle Proof لإثبات أن أحدث حالة أصول للمستخدم A لا تفي ببيان السحب الخاص به ، أي لإثبات أن A لم يسحب الأموال المذكورة بعد الكتلة 100. (تحتوي مخططات البلازما المختلفة على طرق إثبات غير متسقة لهذا الموقف ، ونموذج عنوان الحساب أكثر إزعاجا بكثير من إثبات الإنفاق المزدوج ل UTXO). 2. إذا كان حل بلازما يعتمد على نموذج UTXO (كان هذا هو الحال بشكل أساسي في الماضي) ، فإن رأس الكتلة لا يحتوي على StateRoot ، فقط TxnRoot (لا يدعم UTXO نموذج عنوان الحساب على غرار Ethereum ، ولا توجد حالة عالمية مثل State Trie) تصميم). بمعنى آخر ، تحتوي السلسلة التي تستخدم نموذج UTXO على سجلات معاملات فقط ولا توجد سجلات حالة. في هذا الوقت ، قد يشن جهاز التسلسل نفسه هجوما مزدوج الإنفاق ، مثل إنفاق UTXO الذي تم إنفاقه مرة أخرى ، أو إصدار UTXO إضافي لمستخدم من فراغ. يمكن لأي مستخدم إرسال إثبات Merkle لإثبات أن سجل استخدام UTXO قد ظهر (تم إنفاقه) في الكتل السابقة ، أو لإثبات وجود مشكلة في المصدر التاريخي ل UTXO معين.

1. بالنسبة لحلول بلازما متوافقة مع سلسلة الكتل لـ EVM/State Trie ، قد يقوم الفاصل بتقديم StateRoot غير صالح. على سبيل المثال ، بعد تنفيذ الصفقة الواردة في الكتلة رقم 100 ، يجب تحويل StateRoot إلى ST+ ، ولكن الفاصل ينتقل إلى Layer1 تم تقديم ST- ما تم تقديمه كبرهان الاحتيال في هذه الحالة أكثر تعقيدًا ويتطلب إعادة تشغيل الصفقة في الكتلة رقم 100 على سلسلة الكتل الخاصة ب Ethereum. سيتم استهلاك كمية حسابية ومعلمات الإدخال المطلوبة الكثير من الغاز. واجهت الفرق التي اعتمدت بلازما في وقت مبكر صعوبة في تحقيق براهين الاحتيال المعقدة مثل هذه ، لذلك اعتمد معظمهم نموذج UTXO في النهاية ، حيث تكون براهين الاحتيال على أساس UTXO بسيطة وسهلة التنفيذ. (Fuel ، أول حل للتجميع يوفر برهان الاحتيال ، يعتمد على UTXO)

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

في هذه المرحلة ، يمكن لجهاز التسلسل سرقة أصول المستخدم ،على سبيل المثال ، قم بتحويل جميع العملات المعدنية في الحساب A بشكل خاص إلى الحساب B ، ثم تحويل الأموال من الحساب B إلى الحساب C ، وأخيرا بدء السحب باسم C. الحسابات B و C مملوكة لجهاز التسلسل نفسه. حتى إذا تم الإعلان عن النقل B->C ، فلن يتسبب ذلك في أي ضرر ؛ لكن يمكن للفارز حجب بيانات النقل غير الصالح A->B ، ولا يمكن للأشخاص إثبات وجود مشكلة في مصدر أصول B و C.(لإثبات أن مصدر أصول B مريب ، من الضروري الإشارة إلى أن التوقيع الرقمي ل "Txn معين تم نقله إلى B" غير صحيح). يحتوي حل البلازما القائم على UTXO على تدابير مستهدفة. على سبيل المثال ، عندما يبدأ أي شخص عملية سحب ، يجب عليه تقديم جميع المصادر التاريخية للأصول. بالطبع ، سيكون هناك المزيد من تدابير التحسين في وقت لاحق. ولكن إذا كان محلول بلازما متوافقا مع EVM ، فسيبدو ضعيفا في هذا المجال. لأنه إذا كان Txn مرتبطا بالعقد ، فإن التحقق من عملية انتقال الحالة على السلسلة سيتكبد تكاليف باهظة ،لذلك ، لا يمكن للبلازما ، التي تدعم نماذج عناوين الحسابات والعقود الذكية ، تنفيذ مخطط تحقق بسهولة لصحة عمليات السحب. علاوة على ذلك ، بصرف النظر عن الموضوع أعلاه ، سواء كانت البلازما تعتمد على UTXO أو نموذج عنوان الحساب ، بمجرد حدوث حجب البيانات ، سيؤدي ذلك بشكل أساسي إلى إصابة الناس بالذعر لأنك لا تعرف المعاملات التي نفذها جهاز التسلسل. ستجد عقد البلازما أن هناك خطأ ما ، لكنها لن تكون قادرة على إصدار أدلة على الاحتيال لأن جهاز تسلسل البلازما لم يصدر البيانات المطلوبة لإثبات الاحتيال. في الوقت الحالي ، يمكن للأشخاص رؤية رأس الكتلة المقابل فقط ، لكنهم لا يعرفون ما هو موجود في الكتلة أو ما حدث لأصول حساباتهم. سيبدأ الجميع بشكل جماعي بيان السحب ويستخدمون رأس الكتلة المقابل. يحاول Merkle Proof سحب الأموال ، مما يؤدي إلى سيناريو متطرف يسمى "لعبة الخروج" ، سيؤدي هذا الموقف إلى "تدافع" ، مما يتسبب في ازدحام خطير في الطبقة 1 ، وسيظل يتسبب في تلف أصول بعض الأشخاص. (الأشخاص الذين لم يتلقوا إشعارات صادقة للعقدة أو لا يتحققون من Twitter لن يعرفوا أن جهاز التسلسل يسرق العملات المعدنية).

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

ثانيا ، إذا لم يسمح للعقد بالهجرة ، فسوف يتكبد خسائر فادحة ؛ إذا سمح للعقد بترحيل حالته إلى Layer1 ، فسيكون هناك انسحاب مزدوج يصعب حله في إثبات الاحتيال بالبلازما:على سبيل المثال ، افترض أن البلازما تتبنى نموذج عنوان حساب Ethereum وتدعم العقود الذكية., هناك خلاط ، مودع حاليا ب 100 ETH ، ويتم التحكم في مالك الخلاط بواسطة Bob ؛ افترض أن بوب يسحب 50 ETH من الخلاط في الكتلة 100. بعد ذلك ، يبدأ بوب بيان السحب وينقل 50 ETH إلى Layer1 ؛ بعد ذلك ، يستخدم بوب لقطة حالة العقد السابقة (مثل الكتلة 70) لترحيل الحالة السابقة للخلاط إلى Layer1 ، والتي سيتم نقل 100 ETH التي "اعتاد الخلاط امتلاكها" أيضا إلى Layer1 ؛ من الواضح أن هذا "سحب مزدوج" نموذجي ، أي إنفاق مزدوج.تم ذكر 150 ETH بواسطة Bob إلى الطبقة 1 ، لكن مستخدمي شبكة Layer 2 دفعوا فقط 100 ETH إلى الخلاط / Bob ، وتم سحب 50 ETH من فراغ. هذا يمكن أن يستنزف بسهولة احتياطيات البلازما الجافة。 من الناحية النظرية ، يمكن للمرء أن يبدأ إثبات الاحتيال لإثبات أن حالة عقد الخلاط تغيرت بعد الكتلة 70. ولكن إذا بعد الكتلة رقم 70 ، فإن جميع Txn التي تفاعلت مع عقد الخلاط لم تغير حالة العقد ، باستثناء المعاملة التي أخذ فيها بوب 50 ETH ؛ إذا كنت ترغب في إظهار دليل ، فأشر إلى أن عقد الخلاط موجود إذا كان هناك تغيير بعد الكتلة رقم 70 ، فيجب تشغيل جميع Txn المذكورة أعلاه على سلسلة Ethereum ، وأخيرا يمكن تأكيد عقد Plasma. لقد تغير وضع عقد الخلاط بالفعل (السبب في أنه معقد للغاية هو لأنه يحدده هيكل البلازما نفسها). إذا كان عدد Txn في هذه الدفعة كبيرا للغاية ، فلا يمكن نشر دليل الاحتيال على Layer1 على الإطلاق. (سيتجاوز حد الغاز لكتلة واحدة من Ethereum).

https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598Theoretically، في سيناريو الإنفاق المزدوج أعلاه ، يبدو أنه يتم تقديم لقطة الحالة الحالية للخلاط فقط (في الواقع دليل Merkle المقابل ل StateRoot) ، ولكن في الواقع ، نظرا لأن Plasma لا تنشر بيانات المعاملات على السلسلة ، لا يمكن للعقد تحديد ما إذا كنت ما إذا كانت لقطة الحالة المقدمة صالحة. وذلك لأن جهاز التسلسل نفسه قد يبدأ في حجب البيانات ، وإرسال لقطات حالة غير صالحة ، وتجريم أي منسحب بشكل ضار. على سبيل المثال ، عندما تعلن أن لديك 50 ETH في حسابك وتبدأ عملية سحب ، فقد يقوم جهاز التسلسل بمسح حسابك بشكل خاص إلى 0 ، ثم بدء حجب البيانات ، وإرسال StateRoot غير صالح إلى السلسلة ، وإرسال لقطة الحالة المقابلة ، متهما زورا نفاد الأموال في حسابك. في الوقت الحالي ، لا يمكننا إثبات أن StateRoot ولقطة الحالة المقدمة من جهاز التسلسل غير صالحة ، لأنها بدأت في حجب البيانات ، ولا يمكنك الحصول على بيانات كافية مطلوبة لإثبات الاحتيال. لمنع ذلك ، عندما تقدم عقدة البلازما لقطة حالة لإثبات أن شخصا ما قد أنفق مرتين ، فإنها ستعيد أيضا تشغيل سجلات المعاملات خلال هذه الفترة. يمكن أن يمنع هذا جهاز التسلسل من استخدام حجب البيانات لمنع الآخرين من سحب الأموال. في Rollup ، إذا واجهت السحب المزدوج المذكور أعلاه ، فمن الناحية النظرية ليست هناك حاجة لإعادة تشغيل المعاملات التاريخية ، لأن Rollup لا يحتوي على مشكلات في حجب البيانات وسيقوم "بإجبار" جهاز التسلسل على نشر بيانات DA على السلسلة. إذا أرسل جهاز التسلسل التراكمي لقطة StateRoot-state غير صالحة ، فسيفشل إما في التحقق من العقد (ZK Rollup) أو سيتم الطعن فيه قريبا (OP Rollup). في الواقع ، بالإضافة إلى مثال خلاط العملات المذكور أعلاه ، يمكن أن تؤدي سيناريوهات مثل عقود التوقيع المتعدد أيضا إلى عمليات سحب مزدوجة على شبكة البلازما. دليل الاحتيال غير فعال للغاية في التعامل مع هذا السيناريو. يتم تحليل هذا الموقف في أبحاث ETH. باختصار ، نظرا لأن حل البلازما لا يفضي إلى العقود الذكية ولا يدعم بشكل أساسي ترحيل حالة العقد إلى الطبقة 1 ، يجب على البلازما السائدة استخدام UTXO أو آليات مماثلة. نظرا لأن UTXO لا تعاني من مشكلة تضارب ملكية الأصول ويمكنها دعم إثبات الاحتيال جيدا (فهي أصغر حجما) ، فإن السعر هو أن لديها سيناريو تطبيق واحد ويمكنها فقط دعم التحويلات أو تبادل دفتر الطلبات. بالإضافة إلى ذلك ، نظرا لأن دليل الاحتيال نفسه يعتمد بشدة على بيانات DA ، إذا كانت طبقة DA غير موثوقة ، فسيكون من الصعب تنفيذ نظام فعال مقاوم للاحتيال. ومع ذلك ، فإن تعامل البلازما مع مشكلة DA فظ للغاية ولا يمكنه حل مشكلة هجمات حجب البيانات. مع ظهور Rollup ، تلاشت البلازما ببطء من مرحلة التاريخ.

تنصيح:

1. تم نشر هذه المقالة من [ الاشتراك في WeChat: جيك Web3]. جميع حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [فاوست]. إذا كانت هناك اعتراضات على هذه الإعادة ، يرجى الاتصال بالبوابة تعلمالفريق، وسوف يتولونها على الفور.
2. إخلاء المسؤولية عن القدرات: الآراء والآراء التي تم التعبير عنها في هذه المقالة هي فقط تلك التي تخص المؤلف ولا تشكل أي نصيحة استثمارية.
3. يتم إجراء ترجمة المقال إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر غير ذلك، يُمنع نسخ، توزيع، أو ارتكاب الانتحال للمقالات المترجمة.