على شبكة Plasma، الهيكل الأساسي للكتل مشابه تقريبًا للشبكة العادية، وتتم جميع المعاملات وتغييرات الحالة داخل السلسلة الفرعية. ولكن من منظور التصميم، لم يكن هدف Plasma أن تسيطر الشبكة الرئيسية على هذه التفاصيل.
بعد إنشاء كل كتلة جديدة، يكون عمل المشغل بسيطًا — يقوم بتجزئة جميع المعاملات وبيانات الحالة داخل الكتلة، ثم يُنشئ Merkle Root (بعض التطبيقات تستخدم Merkle Root للمعاملات، وأخرى تستخدم Root للحالة أو UTXO).
هذا Root هو في الواقع:
"بصمة كاملة للتاريخ حتى هذه الكتلة."
وهذا هو الضغط من المستوى الأول. بغض النظر عن عدد المعاملات داخل الكتلة، فإن الشبكة الرئيسية تحتاج فقط إلى النظر إلى قيمة هاش ثابتة الطول.
ثم يحدث ضغط من المستوى الثاني. لا تسعى Plasma إلى رفع كل كتلة على حدة إلى السلسلة، بل تجمع معلومات رؤوس عدة كتل، ثم تعبئها في Root أعلى مستوى. وأخيرًا، ما تتلقاه الشبكة الرئيسية عادةً ليس رأس كتلة واحد، بل هو تعهد موحد لحالة Plasma خلال فترة زمنية معينة.
ما تراه الشبكة الرئيسية في النهاية هو شيء مبسط جدًا: • رقم الكتلة أو فترة الزمن • قيمة Root المقابلة • الطابع الزمني الضروري
الشبكة الرئيسية لا تتحقق من المعاملات، ولا تخزن البيانات، بل تكتفي باعتبار هذه Roots كدليل غير قابل للتغيير على الوقت.
حتى يظهر شخص ما يرغب في الانسحاب أو يثير شكوى، ستحتاج إلى إحضار بيانات المعاملة وإثبات Merkle للمقارنة مع رؤوس الكتل هذه.
لا يتم الحساب عادةً إلا عند حدوث مشكلة — هذه هي المنطق الأساسي وراء ضغط رؤوس الكتل قبل تقديمها إلى الشبكة الرئيسية.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 10
أعجبني
10
7
إعادة النشر
مشاركة
تعليق
0/400
fomo_fighter
· منذ 17 س
أوه، هذه هي "طريقة الكسل" في Plasma، عادةً لا يهتمون بالشبكة الرئيسية أثناء العمل، وعندما يحدث شيء يراجعون الأمور القديمة فقط
شاهد النسخة الأصليةرد0
ApeEscapeArtist
· منذ 19 س
أوه، أليس هذا فن التراخي؟ الشبكة الرئيسية تقول لي لا أركز على التفاصيل، فقط أركز على البصمة، وعندما يحدث شيء، أراجع دفتر الحسابات؟
شاهد النسخة الأصليةرد0
IntrovertMetaverse
· منذ 20 س
فهمت، إنها فن التراخي في Plasma، حيث يتم تحميل جميع الأعمال القذرة والمتعبة على السلسلة الفرعية، والشبكة الرئيسية تكتفي باستلام الطرود فقط.
شاهد النسخة الأصليةرد0
token_therapist
· منذ 20 س
رائع حقًا، فقط لا أريد أن أُشغل السلسلة الرئيسية، وأظهر الأدلة عند الحاجة، هذا النهج في التصميم لا يزال يحمل بعض القيمة.
شاهد النسخة الأصليةرد0
WalletDetective
· منذ 20 س
هذه المنطق المضغوط رائع حقًا، إنه أعلى مستوى من التشفير الكسول، عادةً يكون مديرًا غير مبالٍ، وعندما يحدث شيء يراجع الأمور القديمة فقط
شاهد النسخة الأصليةرد0
FallingLeaf
· منذ 20 س
يا إلهي، هذه المنطق المضغوط مذهلة، عادةً فقط تخزن بصمة الإصبع، وعند حدوث مشكلة تسترجع دفتر الحسابات للتحقق، حقًا فن الكسلان
شاهد النسخة الأصليةرد0
SleepyArbCat
· منذ 20 س
آه يا إلهي، هذه اللعبة... هي فن الكسل، كلما قل العمل على الشبكة الرئيسية، كان ذلك أفضل...
على شبكة Plasma، الهيكل الأساسي للكتل مشابه تقريبًا للشبكة العادية، وتتم جميع المعاملات وتغييرات الحالة داخل السلسلة الفرعية. ولكن من منظور التصميم، لم يكن هدف Plasma أن تسيطر الشبكة الرئيسية على هذه التفاصيل.
بعد إنشاء كل كتلة جديدة، يكون عمل المشغل بسيطًا — يقوم بتجزئة جميع المعاملات وبيانات الحالة داخل الكتلة، ثم يُنشئ Merkle Root (بعض التطبيقات تستخدم Merkle Root للمعاملات، وأخرى تستخدم Root للحالة أو UTXO).
هذا Root هو في الواقع:
"بصمة كاملة للتاريخ حتى هذه الكتلة."
وهذا هو الضغط من المستوى الأول. بغض النظر عن عدد المعاملات داخل الكتلة، فإن الشبكة الرئيسية تحتاج فقط إلى النظر إلى قيمة هاش ثابتة الطول.
ثم يحدث ضغط من المستوى الثاني. لا تسعى Plasma إلى رفع كل كتلة على حدة إلى السلسلة، بل تجمع معلومات رؤوس عدة كتل، ثم تعبئها في Root أعلى مستوى. وأخيرًا، ما تتلقاه الشبكة الرئيسية عادةً ليس رأس كتلة واحد، بل هو تعهد موحد لحالة Plasma خلال فترة زمنية معينة.
ما تراه الشبكة الرئيسية في النهاية هو شيء مبسط جدًا:
• رقم الكتلة أو فترة الزمن
• قيمة Root المقابلة
• الطابع الزمني الضروري
الشبكة الرئيسية لا تتحقق من المعاملات، ولا تخزن البيانات، بل تكتفي باعتبار هذه Roots كدليل غير قابل للتغيير على الوقت.
حتى يظهر شخص ما يرغب في الانسحاب أو يثير شكوى، ستحتاج إلى إحضار بيانات المعاملة وإثبات Merkle للمقارنة مع رؤوس الكتل هذه.
لا يتم الحساب عادةً إلا عند حدوث مشكلة — هذه هي المنطق الأساسي وراء ضغط رؤوس الكتل قبل تقديمها إلى الشبكة الرئيسية.